Software applications age over time like any business asset. Unlike tangible assets, such as physical equipment, software deprecation tends to be less easily identifiable or well-defined. Old software tends to “fly under the radar” in businesses, and as a result the associated risks and opportunities are not addressed in a timely manner. Ultimately, all software has to be rewritten in some form eventually to extend its useful life. Software ages in many different ways but today I want to explore one key way that tends to be easy to overlook when understanding the application development landscape.
Specifications or requirements are the building blocks for any software application. All software development initiatives have to start somewhere even if it is just with an unwritten idea in someone’s head. On the other end of the spectrum, you will find extremely detailed specifications written before any code is written. Most software development falls somewhere in between these two extremes.
At Entrance, we are no different in finding middle ground for requirements. We apply an agile development methodology to iteratively refine requirements as a project progresses. In fact, contrary to some commonly held misconceptions, well-executed agile projects tend to do more planning than waterfall projects over the life of the project.
The way that software ages that I want to address in this post is the morphing of requirements over time. Software is never “done.” In the business world, software is an automated representation of a business process. The world of business is constantly changing. Most businesses are not doing business the same way today that they were 5 years ago. Technology is a huge enabler of business process change. As a result of all the business change that is happening, the software must necessarily continue to evolve to keep up with what the business is doing.
What this all means is that even if you had a detailed specification when you started your software project 5 years ago, it has likely changed quite a bit since then. Undoubtedly some bugs were found and fixed. But more than likely you have more functionality than before or at least different functionality. If you did a good job of managing the process of that change, then you have requirements documenting each change along the way, but not everyone does this well.
As the business logic changes, we incrementally introduce changes to the code to adapt the software. The Association for Computing Machinery’s 2013 A. M. Turing Award winner Lisa Lamport describes this succinctly in a recent article:
“…each patch makes the program and its spec a little more complicated and thus more difficult to understand and to maintain. Eventually, there may be no choice but to rewrite the program from scratch. If we do not start with a specification, every line of code we write is a patch. We are then building needless complexity into the program from the beginning. As Dwight D. Eisenhower observed: ‘No battle was ever won according to plan, but no battle was ever won without one.’”
– Leslie Lamport, “Who Builds a House without Drawing Blueprints?” Communications of the ACM, Vol. 58 No. 4, Pages 38-41.
http://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/fulltext
So, always work from specifications (even in an agile environment), and be prepared to end up somewhere you did not anticipate at the outset. However, always realize that each incremental change introduces complexity that you did not know about at the beginning. Be prepared to eventually need to “rewrite” when the business evolves far past your original vision for your software.