Quality of Coding

Sometimes I think I’m on my own in believing that code should be tidy and consistent, and generally easy for other programmers to pick up and work with. I come across so much code that does the job it was intended to do but is very untidy and has only the barest of documentation.

There are lots of practical reasons for writing quality code but I would like to leave those for now and mention something more personal.

In Zend and The Art of Motorcycle Maintenance by Robert Persig, the concept of quality for its own sake is introduced. Early in the book he mentions one example from his own experience. It has always always stuck in my mind for some reason, and have nothing to do with programming.

Robert had a workshop with a big draw full of heavy tools. Every time he had to get a tool he had the dragging the draw out, which always involved lots of physical effort. One day it got him down and he decided to do something about it.

He went off and bought roller bearings and fitted them to the draw. From that time on he could open and close the draw with a single figure. It gave him great joy every time he used it.

Now the joy didn’t come from the saving of all that physical effort; it came from the pure quality he had built in. Every time he used the draw he felt good about it and himself.

He goes on to talk about how we can all build quality into everything we do. He mentioned how even very mundane jobs can be turned into something really fulfilling by concentrating on doing the job as well as it can possibly be done. In other words building in quality and getting a good feeling from it.

The best way to build in quality is to write it that way from the start. Make sure every line of code is something you are proud of. If you think you will come back later and tidy it up, if you are like me  it probably won’t happen.