High Quality

My Efforts Pay Off

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, at worst a helpful pointer, from colleagues on my code, regardless of whether I ask for it — and I do appreciate code reviews, whether they are formal or informal.

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

O’Reilly Webcast: Maintainability

From time to time O’Reilly.Com offers technical webcasts. Like their books, they are consistently excellent.

Recently I viewed one about building maintainable software, by Rob van der Leek and Zeljko Obrenovic. In it, they acknowledge that doing so is difficult. Everyone must buy in to the goal and maintainability be built in to the source code from the start this website.

Eight Guidelines

In the webcast, Rob and Zeljko present eight best practices for writing maintainable programs. The guidelines, which follow, are measurable and make sense.

  1. Limit length of code units to 15 lines of code
  2. Limit the number of branch points per code unit to 4
  3. Limit the number of parameters for each code unit to 4
  4. Prevent duplication of blocks of code that contain 7 or more lines
  5. Limit the size of modules to 400 lines of code
  6. Try to have 6 to 12 components of approximately equal size
  7. Avoid cyclic dependencies
  8. Keep the code base to 200,000 lines of code or fewer

Experience and Discipline

In conclusion, they state that

“It takes a lot of discipline and experience if you want to write consistently maintainable code.

As someone with a bit of experience, I agree most heartily.

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 lose weight quickly.

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.