Moralistic Programming
I am still enjoying the XP2004 conference. One of the tenets of Extreme Programming is doing the simplest thing that could possibly work. Which means amongst other things, that is the responsability of a programmer to focus on what the customer really needs, and choose the simplest tool available to get the job done.
Today I was reminded again of a kind of reason for not using or creating the simplest possible software. The Shoulds are so powerful, that even experienced Extreme Programmers can find it hard to resist. Examples of the shoulds are: separate content from presentation or its opposite (from ‘naked objects’ all objects should be representationally complete, everything is an object (which has been a favourite of mine for a long time) or they are not using design patterns.
The previous instances of moralistic programming are somewhat easy to recognize, because the ‘should’ or universiality assumption is explicit in the language. It becomes harder to recognize in situations where e.g. a database is added to a program, because the programmers in question always use databases (so it is an assumption), or the choice for a programming language is not taken, because it is more convenient to always use the same tool for the job.
I attended a session on XP Tools. It is easy to assume that such a session is on software tools, whereas XP has re-introduced a number of very powerful non-software tools, such as index cards and face-to-face communication. Many people apparently are still using ANT (an automated build tool)
To a certain extent, I don’t think it really matters very much which tool one chooses, as long as the choice is conscious, and the tradeoffs for choosing one over the other are clear. Unlearning moralistic programming, and doing situational programming more often is a lengthy process for me. What I think helps is to keep on trying new things (I am exploring the SeaSide web-application framework again, which in an interesting way different from other ways to develop web-applications), listen to what other people are doing (conferences provide an excellent opportunity for that) and regularly starting new projects, so it is more often time to select a technology and process that is appropriate for the problem at hand.
