Agile Zone is brought to you in partnership with:

Gojko Adzic runs Neuri Ltd, a UK-based consultancy that helps companies build better software by introducing agile practices and tools and improving communication between software implementation teams, stakeholders and clients. The focus of his work over the last several years has been implementing and improving the practice of Agile Acceptance Testing. Gojko frequently gives public talks on that topic and other agile development topics. He is the author of Test Driven .NET Development with FitNesse, published by Neuri Limited in 2008, and more than 200 articles published in various magazines. Gojko has posted 6 posts at DZone. View Full User Profile

Beware Of The Second Worst Programmer

10.09.2008
| 27253 views |
  • submit to reddit
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.

References
Published at DZone with permission of its author, Gojko Adzic. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)