The article certainly gives good advice: make your software maintainable, generalize when necessary, have a change-friendly environment. But it doesn’t give much help when it comes to the specifics how one might implement these rather general concepts.
Here’s my hint on the matter: I suggest, when you’re sitting down to develop a feature, you design and write the code and the system around it with not only the intent of making it perform the function you need now, but also with the intent of being rewritten later.
An mechanical engineer, when designing a piece of equipment, doesn’t think only about its functionality. He also needs to think about how the item is to be maintained. What parts need to be replaced on a regular basis, and how do you get at those? How do you disassemble the item when it’s not working? These decisions can make an enormous difference in the maintenance cost of the item, and a corresponding difference in the lifetime cost of the item, which may well dwarf the original purchase price.
In the same way, when you’re building a piece of code, think about not only how it’s going to perform its function, but how a later developer is going to be able to change it easily without breaking things.
These changes might be as simple as a small refactoring, or as wholesale as a complete replacement of a program with something else in a different language. Regardless, the developer making the change needs as much help as you can give him to know what the code does, and whether or not his new version is doing the same thing.
The most common way of approaching this is through automated tests, as so well demonstrated (at least for the unit test side of things) in Martin Fowler’s classic book Refactoring. Papadimoulis touches on this when he says, “Testing and quality assurance also need to be resilient to change,” but he doesn’t quite come out and say that usually the testing and quality control is a major part of the change resilience of a piece of software.
This is not to say that automated testing is the only way to to make your code easily rewritable, nor that this is the only reason for testing. But it is a big one, and approaching your testing, along with everything else, with rewritability in mind will help you move beyond testing for the sake of testing and make better software.
I’d like to leave you with epigram 74 from Alan Perlis’ famous list:
Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as soap bubble?