A very nice post by Uncle Bob about rapid software development. We've all done it! Pulling together those quick & dirty hacks in order to meet our deadline. We've created something that works but has messy code and a design that's even worse (= legacy code). We actually believe that we can buy the necessary extra time when we cut corners and rush our way into production stage. NOT!!
The only way to go fast, is to go well.
The truth is out there, and this is it! As described in this post, it all comes down to a matter of professional ethics:
- True professionals keep their code clean at all times.
- True professionals write unit tests that cover close to 100% of their code.
- True professionals know their code works, and know it can be maintained.
- True professionals are quick and clean.
This covers it all, I guess. This brings us to the domain of writing maintainable code.
A good software design minimizes the time required to create, modify, and maintain the software while achieving acceptable run-time performance.
Writing code that works is easy. Almost every developer I've ever worked with can do this. Writing code that works and is maintainable in the long run is very hard and requires a lot of experience and also devotion.
The goodness of a design is inversely proportional to the cost of change.
I've just finished rewriting an existing application. I've got a lot of trouble with reading the existing code in order to figure out what it was doing. This slowed me down a lot. But again, this is probably the reason why I was asked to rewrite this application. Simply because it was hard and too costly to maintain. When something needs to be changed to an application like that, everyone runs out of the room. The fear to break something is taking over.
Creating a code-base that is well designed and maintainable at the first release is a great achievement. Keeping it well-designed and maintainable after many successive releases are heroic deeds. This is were the challenge for us developers lies, not playing around with the latest hype from Redmond or similar. Of course, continuous learning is important but keeping the code clean and refactored all the time ensures that other members of your team don't have to go to a lot of trouble to make changes and implement new features, including yourself.
I'm not saying that I'm already there, but writing maintainable code is one my main objectives. I hope that someday I'll become one of those true professionals.
