Today I had to explain the concepts of disposable software to people whos views I respect. Their reactions were somewhat curious, as rather than tell me I had gone mad, they instead asked me to explain further.
The idea of a model for developing disposable software has been in my head for a while and needed to reach the world. Others have talked about disposable software in the terms of what we know as hacking, this is not what I am advocating.
Lets say you build a 2 bedroomed house, its just the right size for you and your partner and all of the rooms are just as you want them. Over time you will want to improve it as you get a little more money from your day job, so you replace the furniture, replace the bathtub with a jacuzzi and landscape the garden, creating your perfect place. You then have a small child so you redecorate the spare bedroom and fit child safety features all over the place.
So far so good.
Now you hit a snag. Your are expecting a second child and there just isn’t the space to accommodate the needs of two children, so what do you do. You don’t want to move because you have built the perfect home. You can either build an unwanted extension and knock through some walls spoiling the house you love, or move?
What does any of this have to do with disposable software and where is this blog going you may wonder?
Well, imagine that the house is a new system that you have just designed and the children represent unpredicted changes in circumstances. The first set of change was easily accommodated and the system function with little change from its original specification. The second change however was significant enough that it posed a considerable problem, do we make very expensive changes or move on? This problem is faced every day in software development and is a very expensive issue to deal with. Only by removing the emotional barriers in the software process can we make the right decision. Many people prefer a policy of modification over replacement because they don’t like the idea of throwing away all of their hard work.
The big misconception when making a decision on when to replace rather than modify is that replacing a system is more risky than modifying it. This is not always true. Through modification, we are only investing more emotional commitment to the system and we will lose sight of whether it is best serving the needs of the customer. This results in very expensive modification and support costs that will generally eat away at any profitability the changes may have offered.
My case for disposable software is that the removal of the people issues involved when making the difficult and emotional decisions will ultimately lead to the correct decisions being made based on goal and value principles rather than technical and pride related arguments.
So is disposable software just hacking? The answer is definitely NO! All I am advocating is that we need to look at what we can change in the software development arena to produce software that is goal specific, of good enough quality as defined by the customer and not by IT professionals, and will offer true value. The overall aim is to create systems that enable the customer to achieve their aims whilst being of such a low cost that they are expendable, where possible. This does not mean that we ditch the idea of reuse, but only extend the thought processes of reuse to areas that deserve it.
The Dev Cat's Blog 