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.
You make an exceptional point:
>>Often the code is the only maintained artifact that fully describes the current business process or workflow supported by the application.<
You are undeniably right. You have pointed out an assumption that I have, but didn't put in the post: that business process does not live, first and last, in the code. Given the length of my post, I don't know if I'd like to go back and add that tidbit in, but it is important and you are correct for pointing it out.
In the model I'm charged with creating for Microsoft, the business process MUST be described elsewhere, in a tool where the process can be (a) viewed widely, (b) based on shared or mappable ontologies, and (c) 'machine read'. I'm just getting started on this task, but it is an integral part of my committments for the coming year, so rest assured, I WILL deliver it.
If code were not the first and last place for business process... would you still object to the idea of disposable code?