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

4 Comments

  • It is a lot more difficult to write top quality code than code that gets the job done. Anyone who says otherwise has not ever written top quality code.

  • Time is almost always a factor in writing "the best code you can". Not taking shortcuts is only possible when the code is small enough to fit well within a time constraint.

  • I think we are all trying to say the same thing, that we should at all times produce the best code possible, using a measured dose of pragmatism when necessary.



    In my mind, Kenny is taking that stance because of his dislike for ‘developer excuses’. More often than not, sub-par developers, and junior developers will bite off more than they can chew and produce horrid, horrid code that causes massive problems. They will not learn from the experience and take responsibility. For example, they will say ‘I didn’t have time’, ‘I hate my team lead’, ‘The sun got in my eyes’, etc instead of saying ‘How can I do that code better? Did I make a bad choice?’. This type of self-reflection and evaluation is rare to see in people, and the lack of it frustrates me as much as it frustrates Kenny.



    I know a couple people who I think are very smart people, but refuse to pick up a book or read an article by an expert in the industry. Why? Because they think they are the cats meow when it comes to writing code, when it is clear they are not. This has hurt them incredibly, and I wish I could shake some sense in them.

  • On a commercial product you code what you're paid for, no more, not less.... not every commercial product is a work of art.



    There is also a lot to be said for the pragmatic view of "just enough", which doesn't speak to code quality as such but instead feature/function set. The original WikiWikiWeb is the best example of "just enough" in it's right form, and isn't about "being the best that it can be".



    If you're adding a feature or functionality that wasn't asked for, wasn't planned for, and wasn't specified you're not doing what you're supposed to.... and if you're writing the "best code possible" you've just turned your project into an R&D exercise.



    Good commercial code is pragmatic code, everything else is a pet project.



    In terms of marrying prgamatic commercial code, and managing code quality and feature sets formalised versioning is the best way I know of doing this... know ruthlessly what the cut of is for this version, start adding to your list for the next version and the version after that, including code revision along with features. If it's well managed "this module is a hack and needs revised in v1.1" is the *right* thing... and if it's not well managed, a bad team will always be a bad team and will produce bad product.

Comments have been disabled for this content.