Supporting Throw Away Software

4876732522_e4c1c63c4b

The productivity of Friday's HackDay is still resonating with me. One of the reasons why we were able to do so much is that we didn't care about long term support costs of the code that we have written. The difference between a software prototype and a product is that the prototype is cheaper to build but more costly to support. But everything we build in software development is first a prototype and only later a product. We never know exact specifications upfront. Actually the prototype is the first proper specification. A prototype gets rewritten a lot and is quite often scrapped altogether if user tests render the prototype useless. Long term support costs really don't matter for the code that quite probably won't live for more than a few days or weeks. But on the other hand, if code written just by considering short term goals, is shown to be useful and becomes part of the production system, long term goals become much more important and programmers always regret that they haven't written the code properly in the first place.

The short and long term requirements are intrinsically contradictory and I don't have a good solution for this problem. Maybe the solution lies in the ancient observation by Fred Brooks: "Plan to throw one away; you will, anyhow."