I attended a Domain Driven Design course on Monday at Skills Matter offices. Eric Evans led the course and put forward a very interesting theory that the quality of a software system is proportional to the skills of the second worst programmer.
The explanation for the idea is that everyone on the team knows who the worst programmer is, so senior developers are closely monitoring everything that he does and cleaning up problems. The work of the second worst programmer is not monitored with that attention so he has the chance to do some real damage.
Although the story was intended as a joke, it is not completely without merit. Of course, just watching that person as well is not going to solve the problem. The moral of the story is, I think, that code and design reviews need to be done periodically. Most teams I’ve worked with in the past don’t take code reviews seriously, but that is one of the key practices to prevent problems and should not be skipped. Pair programming helps a lot since at least two people are working on the same task, but it still does not protect against problematic code (especially if the worst and the second worst guy pair up).
Drawing a parallel between writing and coding, proof-readers and copy-editors play a crucial role in any magazine or publishing company. They look at the stuff that you have written, identify and sort out (or suggest sorting out) language and grammar issues and look out for stuff that is expressed overly complicated and should be made more clear. An impartial view on the stuff that an author has written often helps a lot to make his text easier to understand and read.
Code reviews matter. Do them often, read code that other people wrote and get them to read your code. Step back for a moment and switch to reading mode rather than writing and check if the stuff can be written simpler or better. Even with the best intentions, people sometimes get blind to unnecessary complexity that they wrote themselves and an objective opinion of another developer can help a lot to sort things like that out. And of course, they might spot things that you have missed while writing the code, intercept bugs and suggest additional unit tests to check potential problems.
Image credits: Jenny Rollo
I'm Gojko Adzic, author of Impact Mapping and Specification by Example. To learn about discounts on my books, conferences and workshops, sign up for Impact or follow me on Twitter.
Join me at these conferences and workshops:
- London, UK, Spec by Example Workshop, 2-3 December
- London, UK, Product Owner Survival Camp, 20-21 January 2014
- Toronto, Canada, Agile Tour, 29 October
- Lille, FR, Agile Tour, 7 November
- Gothenburg, SE, Brewing Agile, 8 November
- Riga, Latvia, Specification by Example Workshop, 11-12 November
- Stockholm, SE, Specification by Example workshop, 14-15 November
- Copenhagen, DK, Specification by Example workshop, 20-21 November
- London, UK, BDD Exchange, 22 November
- Paris, FR, Specification by Example workshop, 28-29 November
- London, UK, NDC, 5 December
- Helsinki, FI, Software development Summit, 9-11 December 2013