The Economics of Disposable Code
June 20, 2007
Posted by on
Nick Malik wrote a post entitled “Mort and the Economics of Unmaintainable Code” where he espoused the belief that re-writing code can be more economical than writing good, maintainable code in the first place.
Rather than look at “making code maintainable,” what if we look at making code free. Why do we need to maintain code? Because code is expensive to write. Therefore, it is currently cheaper to fix it than rewrite it. On the other hand, what if code were cheap, or free? What if it were cheaper to write it than maintain it? Then we would never maintain it. We’d write it from scratch every time.
The post, like others stems from the discussion around Microsoft promoting drag-and-drop controls for Rapid Application Development in .NET.
My concern with this line of thinking is that it assumes that the code only accomplishes one thing: making the application function.
The reality is quite different. The code very often provides much more than pure functionality. Often the code is the only maintained artifact that fully describes the current business process or workflow supported by the application. These days most developers aren’t creating complex UML diagrams or relying on elaborate comments. It has been my experience that when requirements and business processes change, the code is the first and last thing to be changed. When looking at most software, rarely do you find supporting documentation and other artifacts that are maintained as well as the code.
Code drives business value far more than most other artifacts and is thus maintained far better than documentation. While this may not be true in every organization, it has been my experience that any organization that finds itself rewriting code will typically rewrite significant parts of their business processes as well.
Given the choice between rewriting a business process and writing maintainable code in the first place, I think it’s clear which is the more economical approach.