Monday, November 11, 2013

Pragmatism

My background

I'm a .NET, mainly C# programmer. Nowadays I focus on web applications. I usually work on enterprise-grade applications.

I came across Python a year ago on a training session. I was shocked by the syntax but I felt the power of the language and the toolset.

Pragmatism

I think I need to define what is pragmatism for me in the context of software engineering: when a customer has a business problem, your responsibility as an engineer is to choose the proper tools to fulfil the real needs of this customer.

Pragmatic tools

A tool can be a language, a framework, a design or architectural pattern.

Business domain

The real need means a customer usually can't express the whole problem to the team (or even mislead the the team with half or missing information) so the developer (or analyst) needs to dig deep into the business problem and understand the domain before the actual coding gets started.

Pragmatic programming

The first thing is to understand the business domain. A developer has to constantly check the requirements against the customer's ideas and the business domain to make sure there is no misunderstanding. It also applies to the QA (tester) personnel as well. Only the joint work of the analysts, developers and QAs (regarding only the development team) can ensure the success of the implementation considering the business domain and real needs.

The pragmatic programmer does not stick to the favorite language (e.g. C#) she knows:
  • C# is a good choice for GUI, especially with WPF and Windows in mind. On the other hand Python can be a better choice for log analysis, mathematical modeling and statistical processing (considering NumPy, SciPy and Pandas). 
  • WCF (as an XML web service) is powerful for enterprise-grade service implementations but REST can be a better choice for thin APIs with mobile clients.
  • WCF is a powerful end-point provider but node.js can be a better choice if you have an AJAX-heavy web application with some kind of model-based JS framework. In case of node.js you don't need to transform your data from a static-typed language to a dynamic language. Less layers, less transformation, less technology and tooling. 
  • ASP.NET MVC is an easy-to-learn and thin layer for web application development. I like it, but I know Ruby on Rails or even Django (Python) can be as powerful or even more powerful for your particular task.
  • Entity Framework is powerful with its own limitations, but sometimes it worths going back to the basics with direct ADO.NET calls. Or does it? Consider Dapper, OrmLite and such.
  • Object-oriented programming is well-understood but functional elements can make the code more robust and easier to manage.
  • Defensive programming with guards is useful but what about code contracts (even the Microsoft implementation or in general)?
  • Scrum is good and has proved, but how can I adapt it to the current customer? Or shouldn't I choose Kanban? Or Scrumban? Do I need to integrate with an existing project management 'system'? Anyway, do I need to choose an agile methodology at all (yes, it should be prefered :) )?
There are always alternatives and the engineer's job should be choosing the right mix of these alternatives.

No comments:

Post a Comment