The next time that you have the opportunity to re-write part or all of an existing software application, consider performing this experiment.
It is a thought experiment to help you determine what are the most valuable pieces of code that you will write, and perhaps achieve some enlightenment on the nature of software. The experiment can be done in your head or with a pen & paper:
Review the existing application, and find all of the parts that you think are re-usable in your current effort. Perhaps there will be just a few, perhaps there will be none, perhaps there will be a bunch.
Consider each of the re-usable parts and answer the questions:
- why is this re-usable?
- what would have to change in the current effort to make this not re-usable?
Now, skip forward in time and imagine you have successfully completed re-writing the parts that you decide to re-write. It was a wonderful success, and the application has grown and expanded in wonderful ways.
Technologies have changed, it is 10 years in the future, and it is time for the next re-write. Perform the experiment again, and write down the answers that you will want to have this time.
The point of the experiment is to highlight that there is very little value intrinsically stored in source code. The only things that have long-term value are abstractions and standards.
Standards (html, css) are valuable only as long as the technology survives. They are valuable because everyone is dependent on them, and it simply costs too much to abandon them completely.
A sub-category of standards are vendor-specific technologies. Think VB6 forms, .NET forms, ASP or PHP or XAML. They still have value, but they come with the cost of a technology tie-in – they are only valuable as long as the technology lives.
Many standards are a form of debt. You accept that you will get a lower cost of development today, but that the application will only be able to be maintained and grow as long as the technology or standard is viable. It is often a very good type of debt, because there is a balloon payment at the end that you will never have to make (because the application will die before it is necessary).
Abstractions are longer-lived, because they can represent some fundamental domain knowledge. They are valuable as long as the domain and your assumptions do not change.