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
Next Post
Windows 7 Taskbar ... Like!  30 May 2009
Prior Post
Getting the small things right  25 May 2009
Related Posts
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
When are you done?  18 Apr 2022
Fixing GitHub Authentication  28 Nov 2021
May 2009