On Code Quality and Pragmatism
My good friend Ari Glaizel has just started blogging. He is one of the most well-rounded software developers I have come across. I’m looking forward to some interesting posts. He does however tend to be quite pragmatic towards his approach to software development. Talking about working on a deadline he writes:
“If there is a bit more hard-coding than I like to have, that's fine. If there are inherent weaknesses in the solution that’s fine too as long as it’s documented in the code and your team is aware and accepts it.”
I tend to take a harder stance on code quality. I firmly believe that it does not take any more time to write top quality code than it does to write “pragmatic”, just-get-it-done code. The other problem I have is that it’s not enough to document your “hacks” in the source code and make sure you’ve told your team lead (unless he rightly kicks your ass) as it will inevitably be forgotten until one of the assumptions you made about the code is broken just as a potential customer tries to use your product for the first time.
One problem is when you have programmers on your team that do not know how to write quality code to begin with. Even if their managers aren’t breathing down their necks to just get it done, they will inevitably write poor quality code. One of the problems is that it takes years of practice and learning to acquire the experience and knowledge of what it means to write solid code. Students in university are apparently taught that after completing their degree that they are qualified to write production code. Books like Code Complete attempt to bring years of industry knowledge of quality coding practices to the average developer, but I am often disappointed at programmers I come across who feel they do not need to read such books.
The trouble is that it is too easy to say “well this solution will have to do for now – I’ll fix it later” because it is too easily forgotten until it comes back to bite you in the ass and your product support guy asks you why it crashes when you click the File | Open menu item with a mouse but if you use a keyboard to select the command it works just fine (that’s a real bug but I forget in which product I saw it). Every line of code you ever write needs to be written with as much thought and foresight as you can muster because that code will come back to haunt you if you are careless. What is that you say? “There’s a one in a million chance that it will break.” Well, one in a million is next Tuesday.
© 2004 Kenny Kerr