The Economics of Disposable Code

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.

Advertisements

Like this:

LikeLoading...

Related

5 responses to “The Economics of Disposable Code”

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?

Any tool which diligently described business processes would also have to be extremely good at identifying and diagnosing issues with dependencies across multiple workflows as well. This is no easy task even for a human being!
I’m skeptical as to whether an automated system like this could be developed. As the cyclomatic complexity of a particular process grew, routine analysis of the process would take longer and longer.
Even finding such issues with code is often difficult and requires significant amounts of testing or very well maintained unit test suites.
So at best, the tool you are proposing will still need well maintained test cases. So are we really gaining on the maintenance side?

It's very interesting you posted about this; I'm currently talking about this very subject with a company I'm screening for. During the interview they mentioned that the majority of their code is what they consider "throw away" i.e. come time to update or fix stuff, they choose to rewrite. I asked for a few samples, and sure enough they do indeed still code in a 'maintainable' style, so quality appears to be fine, but it was still something I took notice of when they mentioned it.
Nice post.

Nick said:>>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'.<Hmmmm … this is starting to sound familiar … UML … Rational Rose anyone? OK, maybe a little unfair – but the principle of a leaky abstraction is there …The only ‘non leaky’ abstraction of an appliciation, is the appliciation.I know MS as a strategic goal for a long time have wanted to allow business users to write their own appliciations, but until we get the Star Trek computer which can understand me in plain English (and even then in my version of plain English), I think they have an unrealistic goal.The current project I am working on is *all* about business process, but a substantial amount of code is required to allow the nice pretty drag and drop workflow tools to actually do anything useful.

@Casey,
I think you may have it backwards. The application is the leaky abstraction of the business process. We are attempting to automate all the intricate details of the business process and we are attempting to make it simple, but those intricate details keep leaking through the application, and we have to write 500 page books on how to handle the exceptions and support the code and all other kinds of nonsuch.
In reality, if automation didn't have the benefits of speed and reliability, it would be too complex to do it.
I never said that my "machine readable" library of business processes would produce applications. It won't.
To keep from having the business process complexity leak through the application and up to the users, developers, support engineers, and budget jockeys, we have to reduce the process complexity to the level that a human can handle. Then, a human will be able to handle it.
The current path is a dead end. The law of leaky abstractions proves it.