magpiebrain

As you’ll no doubt of heard many times, most problems in computing can be solved in a variety of ways. Knowing which (if any) of the known solutions are best, is typically down to experience, and the desire to experiment with unknown solutions that could yield positive benefits. In a project context, it can be all too easy to just do the known thing – better the devil you know and all that. However if managed properly, there is scope for limited experimentation during a project.

A colleague of mine has successfully used the approach where new best practises are adopted for a short duration – such as a a single iteration. I would actually advocate these best practises being very rigidly enforced, more so than normal. The aim is that people get a good feel for another approach, and will be better able to make an informed judgement call in the future. Such altered practises might include things as simple as “no getters allowed”, or “use the visitor pattern instead of the iterator pattern”, or more process oriented changes, such as automatically running “findbugs”:http://findbugs.sf.net/ when you check in to CVS, or “hansel(Automatic code coverage of JUnit tests)”:http://hansel.sf.net/ when you run your JUnit tests.

The important thing here is that you review (at least informally) the impact of the change afterwards – and don’t be afraid to decide it wasn’t a good idea. Saying “no getters allowed” may well promote “tell don’t ask design(The pragmatic programmers on tell don’t ask design)”:http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html, but should be used as a guideline rather than a rule. Running findbugs on every checkin might slow things down too much, or you might find the output not that useful. It’s also important that you choose a duration short enough that it doesn’t adversely affect development, but long enough to be a reasonable test of the new approach – I’d say at least a week, but no more than two before an informal review takes place.