Designed to be thrown!
amit March 15th, 2006
When radical change is part of the plan, “Use and Throw” is an effective policy. Agility and adaptability afforded by such policy are not only defensive traits in the face of a rapidly changing environment, but can easily be harnessed to gain significant competitive advantage. “Use and throw”, might precipitate the idea of waste, but on the contrary, software designed with such an objective would minimize exactly that - waste.
More times than not we tend to over estimate the useful life of software, consequently investing more than we really should, and ending up doing a trapeze act; trying to balance between taking advantage of technological advances, improved processes etc and hoping for a decent return on our investments. This is how “legacy systems” are born. The infrastructure that was supposed to liberate us, binds us. We can talk about being scrupulous in our investments and light weight in our designs to ad nauseam, but nothing drives the point more forcefully and eloquently than the simple concept of “Use and Throw”. It is with this conviction that I would like to explore few idioms to built software so cheaply that it is designed to be thrown.
- Use generic components and resist the urge to ‘personalize’; Googled an open source component, or a third party inexpensive toolkit, plug it in - use it as is. Innovate (read work around) beyond its shortcomings. Remember we can’t spend months building something that will last weeks. Make it work - now.
- Move to high level languages; use Python, BPL or workflows whatever. Get more done with fewer lines of code. However be cautious of vendors who advertise few lines of code at the top but require esoteric libraries at the bottom, run far from .dll’s and .so’s, understand your underlying infrastructure. Finally for God’s sake, please don’t compile.
- Try and use time tested, widely deployed or easily available resources. Shun the “latest and greatest”, you can do without it. It is my contention that if similar application and energy devoted to learn the latest advances is applied to make do with what’s standard, better software would be produced faster. Think about building on top of the file system, http, html etc. Try to be platform agnostic, but if you can develop quicker for a specific platform by all means do so.
- Don’t generalize, remember this is going to be thrown - simply try to solve the problem at hand. You don’t need a configuration file. Hard code, it’s not always a bad practice. And if you are thinking interfaces, or three tier class hierarchies be reminded - the fact that a refrigerator and a dryer are both Object is of no use at all. You cannot chill your beer in the dryer.
- Strive for transparency; this is another reason to shun compilation. Let your users see the code, if need be, a bug fix could be as simple as asking your user to edit a simple text file. Alright if you have to be fancy you can mail it to them. The same goes for configuration, if you absolutely need configuration - put it in code. This is a popular scripting idiom, users can change config.py just as easily as they can change config.xml. Here is an example config.py.
config = {} config['LANG'] = ‘ENG’ // options GER, FRN or SPA config['TEL_NO_FORMAT'] = ‘xxx-xxx-xxxx’ config['ERROR_CHECK'] = ‘YES’ // option NO config['DEBUG'] = ‘FALSE’ // option TRUE
- What is the most effective and also the most popular form of code reuse? Ctrl-c Ctrl-v, use it, it works all the time.
The only thing predictable about the future - is that it is unpredictable. Change not only takes place, unfortunately it takes place at an ever increasing pace. In my view the era for “Use and Throw” software is here, and sooner we start thinking about it the better. Of course not all software is “Use and Throw”, but a lot of it can and should be. Besides which problem would you rather face?
(a) How to extend the life of an application that was built cheap, designed to be thrown?
(b) How to make use of this enterprise software (read, worth thousands) designed to exchange data with a supplier you don’t like?
I guess you could always wear deodorant if your supplier stank.