Several of the tips that I included in my recent user group presentation Towards Maintainability were oriented towards improving the quality of the code - making it easier to understand, safer to modify, and so on.

A recent post How TDD and Pairing Increase Production on the Situated Geekery Blog is making a similar point, though from a different perspective - that of increasing productivity now rather than maintainability later.

The author (“GeePawHill”) writes

If you want more production, look first to raising your internal quality

Internal quality … is about the code … It’s about crossing your t’s and dotting your i’s.
It’s merciless refactoring, delightful pairing, and using microtests to drive the code.

All day long, every time you make a move, you will be depending on the code that’s already there. Every line of it you have to study will slow you down. Every extra open dependency will slow you down. Every bad variable name will slow you down. Every flawed design decision, be it big or small, will slow you down.

If you want to work as fast as you can, you want to work with clean code.

(Emphasis added)

I totally agree - if you want your code to be as maintainable as possible, it needs to be intelligible, consistent and predictable. The few seconds it takes to write tidy code instead of a mess are repaid manifold, often by the end of the day.

The rest of the post is well worth reading too.


blog comments powered by Disqus