I have just read an excellent post Agile Process Reality Check by @ralfwen. Many things he wrote there strike me as very insightful and I twitted some of them. But where he really “got” me was here:
We need a development process, which addresses today’s major challenge evolvability head on by putting much more pressure on a code base through shortened evolution cycles.
I have spent most of the last 10 years developing and maintaining a single code base and it fundamentally changed my approach to development. I was always sticking with projects for significant amounts of time, but the most I spent in touch with a code base before those 10 years was 3.5 years. Time enough to hurt and get bitten a lot but not enough to understand just what I was missing in order to make code easily maintainable.
I blogged about it last year in Commenting Code is Teaching:
…even if you had a way to perfectly communicate intent through code, what your code will never have, indeed cannot have is what at the end wasn’t coded. The coding is an art of not only what has been written but also what hasn’t been written.
Now that I’m rereading that post it isn’t clear from it, even to me, that what is driving my passion for the subject of commenting is the desire to code in such a way as to later be able to efficiently maintain a code base for years (decades!)
Ralf says something similar as well:
To check the fulfillment of functional requirements, execute the program. To check non-functional requirements, execute the program. To check the evolvability, evolve the code.
Evolvability is the part that hasn’t been written and cannot be written in any way in the code. We can develop the code in such a way to make it more maintainable, easy to fix and evolve. But that quality is impossible (at least by me) to measure (echoing a sentiment from ZAMM). And since it cannot be measured and thus cannot be put in a tight feedback loop it has to be part of the culture of coding, of our craft and of our standards of excellence.
Last modified on 2013-05-25