The Shelf Life of Code
October 5, 2009
Posted by on
There’s a lot of discussion going around about the evolution of software development towards building in long term quality and maintainability up front using practices like TDD. A lot of it was sparked by Joel Spolsky’s praise of the Duct Tape Programmer. The latest post in this discussion that caught my eye was Scott C Reynold’s Quit Living in The Past – Practices Evolve.
While I agree that “time to market” is an important driver for software, it shouldn’t be the catch-all excuse for building low quality solutions. Too often I’ve seen time to market gains get erased by the high cost of software maintenance and production support down the road. The current codebase that I’m working in on a daily basis was written by a few Duct Tape programmers and now my company is paying a high cost to satisfy existing customers while attempting to increase market share with a creaky solution.
The fact is, many businesses keep code around for a lot longer than we as developers would like. Software has become the life blood of many businesses and is very costly to construct, so getting applications out the door quickly and planning for a full rewrite every few years is rarely a good business decision.
Good developers are also becoming scarce, especially when looking for those that have recent experience with legacy technologies. This is because developers with talent are wanting to constantly evolve into new technologies and stay challenged. The only way to retain this talent and utilize it is to have a constantly evolving codebase. If the foundation of the software incorporates a lot of technical debt that is completely dependent on legacy technologies, a business will have a lot of trouble finding and retaining skilled developers to work on it.
These conditions all appear to run contrary to each other. Businesses want to keep working code around, but Developers don’t want to keep working on the same code. Development Managers have to keep their businesses happy, but still find and retain skilled talent.
So what’s the answer? Build quality and long term maintainability into the codebase up front. Abstract your Persistence from your Service Layer so that you can swap out data access technologies every few years. Separate your Domain from your Presentation so that you can swap between web technologies when appropriate. Make unit tests a requirement for your codebase so that you always have a solid safety net when you break ground on new technologies. Build a suite of automated acceptance tests against your User Interface so that you’ll know that something broke long before your customers find it. Release early and release often so that your software doesn’t stagnate and you can maintain and increase market share.
Another big red flag is when you have individuals that knowingly cut corners because they don’t believe software should have a lifespan of more than 3-5 years.
These days businesses the shelf life of software is increasing dramatically as more core businesses b