Designed to be thrown!

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 just as easily as they can change config.xml. Here is an example
    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.

About amit

I was born in Kanpur, India in 1977. I did my schooling partly in Kanpur, Surat and Udaipur. I spent most of my schooling years in Udaipur in a boarding school. This was the most enjoyable period of my life predominantly because I made a lot of friends and played a lot of football (my first love). My school years brought in a sinking realization that I was good in academics, average in football [even after my most sincere efforts :( ] and to put it euphemistically 'artistically challenged'. Hence cool careers in photography, sports, art & design or music were all beyond me. I took up what I could do best, and enrolled for engineering at Nagpur University. College brought its own pleasures, I had my share of beers, bunked classes, read the 'Bhagvad Gita', learned yoga and picked up love for traveling. After graduating I was one of the lucky few to get a great job at Infosys Technologies. The best thing I got from my first job - my Yamaha Rx 135. There were not many weekends when I did not explore places in and around Bangalore on it. In two years though my desire to pursue further studies caught up with me and I enrolled for a M.S in Computer Networking at North Carolina State University. Here I picked up basketball, love for stand up comedy, liking for the 'other football' and offcourse a little bit of computer networking. I graduated in Dec 2002 and am currently working for /n Software. I am slowly evolving into a die hard Linux and Open Source enthusiast, trying to pick up skydiving, biking, running and photography. Some might call that progress. :)
This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published.

To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image