High Quality

The Conscientious Programmer

Because of previous experiences, I always take great care to try to write clean code that is easy to maintain.

These efforts have paid off! I have always received positive feedback — and at worst (best?) a helpful pointer — from colleagues who have reviewed my code.

As this short essay and this page on Stack Overflow demonstrate, there are plenty who agree with me in this respect.

Is Conscientiousness Obsolete?

As things change more and more quickly, some people might assert that being careful is no longer important, because today’s technology will soon be obsolete. More and more we see this, as technical debt increases to the point where legacy systems require total replacement.

This is certainly a valid point, and we need to be mindful about how much time we spend chasing an idea down a rabbit hole and trying to make things just exactly perfect.

Not So Fast!

Another side to this idea is that, because things change more quickly, it is our professional responsibility to help others embrace this change by writing more maintainable code.

As the trend away from full-time employment towards temporary gigs continues, it becomes more important for the next person — whose experience may be vastly different from our own — to be able to quickly understand how the current system works, so they can quickly make the desired changes.

My Personal Preference

Obviously, I can see merit in both sides of the debate.

But to be perfectly honest, I prefer to be conscientious, perhaps because it’s in my nature (I grew up with a lot of guilt).

When done with a project, I like to feel good about what I’ve done. I like to be confident I’ve done a good job and didn’t just “hack something up” to meet a deadline — not that there’s anything wrong with that — provided it’s what the customer wants.

Preventing Misunderstandings

Here are some techniques that can help alleviate possible misunderstandings when it comes to quality:

  • If you are planning to replace a system and just need a very few minor but important changes made, be sure to state this up front, so that we know that in this instance quality is unimportant.
  • Setting a fee for the finished product, based on its value to the customer, is preferable to paying for work by the hour. The set fee scheme alleviates the risk of unwillingly paying more for “high quality,” which can be difficult to define and in some cases even be totally undesired.
  • Stating up front that your company is on a strict budget and at this time cannot afford any extra expense for “high quality.” If you are interested in improving things once the company’s finances stabilize, this is good to know, because we can leave “TODOs” in the code to help the next person.
  • Building a “quick and dirty” prototype. A true prototype should be built with the intent of discarding it and starting over from scratch, if and when it proves the viability of your ideas. If you think the prototype might go into production at some future date, be sure to mention this up front.

In my experience, few clients will say they do not care about high quality, but their preference makes itself apparent in other ways, which can be unfortunate.

Direct communication is always preferable to nuance — which is easily lost when working remotely.

Over-Thinking or Due Diligence?

I like to take my time when solving a problem. More than once I’ve coded up a complicated solution, only to take a look at it and figure out a much simpler way to do the same thing.

To some, this is over-thinking. To me, it’s due diligence.

I like to come up with multiple solutions and pick the best one, rather than rush to implement the first idea, even though the initial solution might be sub-optimal.

Communication is Key

Moreover, if I am working for you on an hourly basis and you prefer I deliver an end result that might be something less than “just exactly perfect,” please state this up front.

Properly communicating your preferences allows me to keep an eye on the finished product and deliver an optimal result, regardless of whether we agree on what exactly constitutes “high quality.”

A Passion for Maintainable Code

Thanks to a book, named Code Simplicity, I finally realized one of the main things I love about programming so much.

Finally, after many years, I have discovered my passion! And that is: writing code that is easy to understand and maintain, and this boils down to keeping code as simple as possible.

The book analyzes the value of software, the effort needed to maintain it, and the desirability of the changes, even though we cannot be sure what the nature of these changes might be.  And it comes to the conclusion that all code needs to change eventually, and the future cost of making these changes is more significant than the initial cost of development.

The book made me realize that the real cost in software is not in the development of it, but in the maintenance.  By taking a little extra time and ensuring that code is maintainable, in the long run we save money.

And that is what I really enjoy about writing software.  Once I get a program to work once, I don’t like to stop there, the way some people do.  Instead, I like to take the time to look at what I’ve written and ask:

  • Does it make sense?
  • Could what it does be done any more simply?
  • Is there any cruft, any dead, unused code?
  • Will a new person understand it, quickly and easily?
  • Will a new person fix or enhance it, quickly and easily?
  • Will I understand it, quickly and easily, if I need to change it, in the middle of the night, a few years from now, or both?

To tell the truth, I actually have at times felt guilty about taking this extra step.  After all, the program works, why spend more time on it?  And of course there are times when I haven’t been able to take this extra step, and have regretted delivering something that I am not very proud of, something I know could be better, if only there was a bit more time.

This blog contains stories about the benefits of well-designed, easy to maintain code, and the hazards of poorly-designed, difficult to maintain code.

But I still encourage you to buy the book.