Dec 29 2007
FitNesse.org has been offline for a few days now. I’ve set up a simple web site with some
basic information on FitNesse and a copy of the latest release as a backup solution for download when the main site is down. See
http://www.fitnesse.info/download if you want to download the latest release until the main web site goes online again.
Dec 27 2007
DbFit 0.93 has just been released. Pick it up from SourceForge.
Dec 26 2007
Kuniaki Igarashi posted a nice presentation on Omoiyari-Driven Development, with the core idea of programming while keeping in mind how other developers are going to use and understand your code. This practice aims to reduce misunderstandings among team members. I have a strong belief that communication and communication-related problems play a key role in software development, and although I would not consider being thoughtful of others as an idea that can lead development, I certainly agree with Kuniaki that it is a very important practice. I wrote several articles about related techniques, including Documentation for telepathic developers and The Poka-Yoke principle and how to write better software.
I am pointing to this presentation mostly because of the secondary “Bear programming” practice, which revolves around explaining the problem first to an imaginary team member (or in this case a real stuffed toy bear) before raising the flag and asking for more help. When a team member asks a question that clearly signals that he misunderstood the issue or the underlying infrastructure, I always try to lead that person into expressing the problem better or drawing it on paper. Very often that team member will reach a good conclusion himself - expressing it on paper or to another person just helps to clear the issue in his mind. This is, in my experience, much more effective than just giving an answer straight away. Bear programming speeds up the process a bit and includes a virtual person for people to talk to.
A stuffed toy is, however, no replacement for an experienced team member - and if agile development has thought us anything it is that there is no replacement for direct person-to-person communication. Asking for help is a good thing and I would not want to prevent people from doing that. But this can be a very useful practice to prevent junior team members from wandering off into the wilderness when they hit a problem. I would suggest using Bear programming, but with a different trigger - before starting to develop some utterly complex workaround, explain the problem to the bear. If that does not help, then raise the flag and call someone to assist you. Using the commander’s intent template can also help a lot to improve the shared understanding - so if you are often getting these problems ask yourself whether you can explain stuff better in the first place.
Dec 20 2007
I started compiling a list of Oracle SQL and PL/SQL bad practices, with the intention of producing a comprehensive catalogue of common and recurring programming mistakes, that can be used as a check-list for code reviews or given to junior developers. I have identified about 30 bad practices so far. For each bad practice, I provided a list of symptoms in the code, an explanation why it causes problems and a list of preferred solutions.
My goal with this list is primarily to start a discussion about similar recurring issues that other people have noticed. That discussion should lead to a more complete list which the community will then be able to use, hopefully, to learn something from the mistakes of others and to produce better code.
You can download the first version of the catalogue in PDF form from http://gojko.net/effective-oracle.
Dec 13 2007
Alt.Net conference on using alternative developer libraries and tools on Microsoft’s .NET platform is coming to UK. The official conference web site still does not give out too much information, except the date and location - central london, Friday 1st and Saturday 2nd Febuary 2008.
