Disposable Software  

By Alex Bunardzic under Theory on 16. August 2005

I was recently hired to deliver a presentation on the Goal Oriented Software Design. The added twist to the challenge was that the presentation was supposed to be narrowly tailored to the client’s business domain, with some concrete examples. That meant that I couldn’t get away with just a generic presentation – I had to invest some serious time in research, before I was able to even think cogently about the specific problem.

The paying client was clear about that requirement, and was happy to oblige me. Not before asking me for the estimate, though, which ended up in thousands of dollars. Having no particular objections to my estimate, the client signed the SOW, and I went off to merrily prepare the presentation.

But then that episode got me thinking. Here we have a budget-conscious company, signing a hefty invoice in order to consume the presentation that basically got delivered to them within one hour (that’s all it took for me to run through my slides and to fend the QA period). That presentation was a one-time event, a throwaway, if you will.

Now, imagine if, instead of negotiating for a presentation, I was involved in negotiating the delivery of a software application with the same company. Would I be able to get away with thousands of dollars invoice for delivering a throwaway application that would only address a very narrow and specific problem domain and that only for a very short period of time?

The answer is, of course, a resounding ‘no way!’ No one in their right mind would ever approve building an application that would be useful only to several people, and only for a couple of hours/days.

But really, what’s the difference between such an application, and the presentation that I’ve delivered? My presentation, while doubtlessly viewed as being quite useful to several expert users within that company, was valid only for an hour or so. The fact that it took me more than two weeks to prepare something that will have useful lifespan of only an hour or so apparently didn’t seem to bother anyone. A software application, on the other hand, gets invariably perceived as being something that not only must possess phenomenal longevity (at least 3 to 5 years, according to the current rule of a thumb), but must also offer a huge portion of salvageability, that is, reusability.

A typical business presentation, such as the one delivered using Microsoft PowerPoint, is not expected to be reusable. In truth, however, there usually is quite a wealth of useful information and knowledge buried inside such typical presentations. But no one seems particularly bent on salvaging that content, or on reusing it, or on evolving it, etc.

But as soon as we step into the world of software application development, the delivered source code, and all the embedded knowledge it carries within, gets treated as pure gold. All of a sudden, everybody starts hyperventilating about the ability to reuse it, not to reinvent the wheel, yadda, yadda, yadda.

I must admit at this point that I’m a bit mystified as to why would one kind of knowledge (i.e. the knowledge embedded within software source code) be so extremely precious, while another kind of knowledge (i.e. the knowledge embedded within other business documents) be viewed as easily reproducible and thus not worthy of extreme ritualization. Especially when often times the two apparently different kinds of knowledges turn out to be quite similar in scope and in intent.

Something is terribly mystified (beyond any recognition) in the world of software application development. If someone is prepared to spend several thousands of dollars on articulating and communicating certain valuable, albeit disposable message to the targeted narrow audience without even batting an eyelash, yet at the same time balks at similarly useful articulation of the equally important knowledge to be delivered via the software application code, that tells me that something went haywire along the way. Reality check is in order.

On the flip side, however, I had to ask myself how is it that I feel perfectly comfortable delivering all those disposable PowerPoint presentation without ever looking back, and yet at the same time I find myself striving to build the software code that would be as general-purpose as is humanly possible? Am I being reasonable in behaving that way?

If someone asked me to deliver a PowerPoint presentation outlining the optimal strategy for building a teacher’s grade book that would collect assignments and quiz marks and grades and summarize them into the final grades, I would gladly jump to the challenge and quite comfortably ask for 5 to 7 days of research time. I would be quite certain that I could deliver a high quality product in that time frame, starting from a completely clean slate.

However, if they asked me to deliver the application code that would allow teachers to collect all the grades and summarize them for the current grading period, according to the particular rules that the school in question operates under, I would be reluctant to jump at it and commit to delivering it within the 5 to 7 days time frame.

Why, what is different with the software code compared to the PowerPoint content? Basically, the fact that both current technologies in vogue, (both Coke and Pepsi, that is, J2EE and .NET) are so complicated, prevent me from feeling comfortable in delivering a highly customized solution.

But, realistically speaking, I think it is becoming more and more clear that delivering huge, bulky, all-things-to-all-people software applications is simply not the way to go. We are now ushering into an era of disposable software. Build it quickly, with a particular narrow problem in mind, and for a particular, possibly short time frame of valid use. Then, be prepared to throw it away, and to move on, not looking back.

Up until recently, such a thing would sound more like science fiction, but today, thanks to the new generation of tools and new outlook on the philosophy of software development, such an approach is becoming increasingly feasible. I will give a brief illustration here:

Last year I worked on a project that aimed at delivering administrative functionality to the school districts throughout the North America. The project was conceived and driven by a high tech company, itself driven by various high tech concerns and agendas. Thus, we ended up with the ungodly mixture of .NET, J2EE, and a bit of the Oracle technology thrown in for good measure.

But the real problem was in the lack of true focus. The product was being built with a vague, generic individual user in mind. Thus, most of the features that the product offered were completely amiss. And because the end-user acceptance was so poor, the all-knowing higher-up powers started driving even harder towards generalization and future flexibility. Which means, when translated to dollar value, that the application was exorbitantly expensive to design, develop and maintain.

Because of that, it was put up on a pedestal, and was treated like a sacred cow in all ways imaginable.

Anyone who would dare suggest that, instead of attempting to build one giant, general purpose app, we focus on building several more specific apps that would address specific needs of individual districts (or even schools), would be shunned, ridiculed, and eventually thrown out of the boardroom.

Thus, we’ve ended with an extremely precious product that had myriad of features that end-users mostly didn’t care about. But, the final product is now exorbitantly expensive. Would anyone dare, at that point, tell the powers that be that such a product should be just a throwaway? Not a chance in hell! And so the dance of deception continues.

Meanwhile, all that the targeted segment of end-users wants is a simple app to allow them to do their job easily. And they are not thinking in terms of many decades of blissful use. Just let them do the specific job right now, for this specific event (such as submission of final grades).

In reality, a good software developer should be able to do just that – deliver a disposable, short lived product that addresses only the pressing needs of the moment, and then simply disappears. No maintenance, no enhancements, no song-and-dance, nothing. Similar to how my one-time business presentation required nothing more but to simply be consumed, and then thrown away. No fuss, no muss.

17 Responses to “Disposable Software”

  1. Douglas:

    Give your school apps an RSS output and you can be happy that the users aren’t throwing their grades down a black hole too.


    comment at 17. August 2005

  2. Danno:

    I think part of this is that software developers are lazy enough bastards that they think to themselves: “Crap, I don’t want to have to write this again, I oughta try doing it right the first time.”

    So they plan and plan and plan and try and do something that’ll be good enough that no one asks them to work on the same problemset again because they’re already bored with it and it ends up a giant ol’ mess because what they end up doing is trying to capture the really, REALLY hairy reality of Bureaucracy and the sub-system of Bureaucracy that makes sure that when the business rules don’t cover something, shit can still get done anyhow.

    And THAT is where it breaks down, because the attempt to model information flow when you are given incomplete information on the flow of information is futile.

    The reverse, I think, is why people want large, dependable, “Enterprise Level” software systems: They’re willing to adapt their bureacracy to a software package provided that it’s close enough that they don’t have to change TOO much.

    Did that make sense? I think I started rambling somewhere.

    comment at 17. August 2005

  3. Jared:

    I deginitely agree with this. In fact I wrote a somewhat similar article a little while back that talks about actually abandoning software that still serves a purpose. Just thought it would be a nice follow-up to this article even though it is not exactly on the same topic.

    comment at 17. August 2005

  4. Assaph Mehr:

    While I firmly believe like you in disposable software, I think there is something wrong with your first argument (presentation vs. software). It’s the old ‘teach a man to fish’ story: your presentation is not about giving them a one-time fish, it’s about teaching them how to fish (with examples for their lake, as it were :). If you just hand someone a piece of software (particularly closed-source) they have something they can use directly for a while. The impact of your presentation is not less than the software. The presentation is not reusable by you, but it is by them - every time they think of the problem.

    In the long run, if your presentation changed the way they think it will have more of an effect than the software they used for a few months. Conversely, if they buy the software they want to make sure that it lasts as long as possible (not just value for money, but also because people hate change; they want something that will still be comfortable in the future).

    I imagine disposable software - even though it is the right idea - will make people uncomfortable. We as developers all know that stable requirements are myths, and that coding is almost always done in maintenance mode. The user may not realise this. They may not understand that their own perception of their needs will change over time, and thus they are after something stable. In their mind, this justifies the cost of “enterprise software”. It is up to us to show that disposable software, using open-source components and agile methods - is actually better and cheaper in the long tun.

    comment at 17. August 2005

  5. Douglas Clifton:

    Regardless of the perception at a corporate level, most software is disposable. Every few years, the operating system you use becomes obsolete, the applications are outdated and upgraded, the hottest thing is now stale. Look at Lotus, or OS/2, or countless other examples. I recently moved across the country. I had to clean out a lot of stuff. I threw away boxes and boxes and boxes of software, manuals, etc. (and a lot of hardware too). Some of it, in its heyday (AutoCAD for instance) was very expensive, $1000+ per seat. Now useless. Can you offer old software to a library, like a book, so someone gets some value out of it? They’re not interested, in the dumpster it goes.

    comment at 18. August 2005

  6. Ryan Tomayko:

    Shirky’s Situated Software makes a similar case. Not for disposable apps so much as small and specific, one-off type apps being a whole area of application design that is important and valid yet largely unexplored by the “web school”. The essay is well-known and cited heavily but I like to throw it out at every chance. Definitely an important work in shifting my perception of the software landscape.

    comment at 18. August 2005

  7. ludo:

    If the organizationis sufficiently large (eg 10k employees or more), the bulk of the costs for a new application are deployment, change management, application management, training, etc. The development phase is a very small part of the whole process. Just think of all the meetings that are required to bring an app online, and what their cost is to the company.

    Where I work (large financial institution, about 40k employees) the thing managers are most scared of is having to maintain something after it has been released. Oh, and a small app means a small budget, they only start the process to develop a new app if it substantially increases their annual budget.

    comment at 18. August 2005

  8. Dan Hatfield:

    From what I can tell most corporation do pursue reuse of “content” (presentations, documents, etc) in the form of knowledge management. Of course, based on my experience, these initiatives have been as unsuccessful as reusing code modules.

    comment at 18. August 2005

  9. Matthew:

    Fantastic article. We write “throw away” code here all the time.

    comment at 18. August 2005

  10. Jonathan Holst:

    I agree with Assaph Mehr, on the part that there’s a difference between the software and the presentation — the presentation might make you smarter, and that’s precious.

    comment at 18. August 2005

  11. alexbunardzic:

    Douglas Clifton wrote:

    “Regardless of the perception at a corporate level, most software is disposable.”

    Thanks for this clarification, Douglas. You are, of course, right, and now I see that I should’ve titled my blurb “Intentionally Disposable Software”. Because that’s what I was driving at.

    comment at 18. August 2005

  12. alexbunardzic:

    Assaph Mehr wrote:

    “While I firmly believe like you in disposable software, I think there is something wrong with your first argument (presentation vs. software). It’s the old ‘teach a man to fish’ story: your presentation is not about giving them a one-time fish, it’s about teaching them how to fish (with examples for their lake, as it were :). “

    This is true, my example is all about ‘teach them how to fish’. I chose that example simply because it was first hand and my most recent experience, so I talked about it in order to lend more credibility to my thesis.

    However, I can also cite many examples where the PowerPoint presentation was merely a fish to be devoured by the audience, not a lecture on how to fish. In that respect, such presentations are not that much different from what a business application can deliver to its consumers.

    Using a run of the mill application is not going to make anyone smarter, that’s for sure, but the same holds true for consuming a run of the mill business presentation.

    comment at 18. August 2005

  13. Peter Wilson:

    I hate to break a big secret, but power users (and departmental programmers) have been using Micorsoft Office to develop small disposable systems for years. It seems this lesson has not yet been learned for web based apps.
    As an example our Ski Racing Club developed a very simple system for the annual club auction. Simple Access tables and a few forms + crappy coding that would make a programmer cry. Invaluable: one hour end-of-auction check out lines reduced to minutes. So useful that several other clubs have lifted it out of the garbage can for their own use.

    comment at 18. August 2005

  14. Ethical Software by Alex Bunardzic » Building Disposable Software with Rails:

    […] Last year I became aware of the Disposable Software phenomenon. After using Rails on a couple of initial projects, I also became aware that the reality of disposable software is upon us. Today, I’m going to show you an example from my recent practice. This example will hopefully support my hunch that the age of disposable software is dawning. […]

    pingback at 09. August 2006

  15. Peter Rip:

    I think this is a brilliant insight. It is the core of Web 2.0 impact in the Enterprise.

    comment at 25. August 2006

  16. Team Murder » I’d Rather See Recyclable Software:

    […] I spent a little time on the bus ride this morning reading and mulling Alex Bunardzic’s post on disposable software which is a huge lump of information and insight to chew on but it also got me thinking about some things perhaps tangential to some of the things he talked about. In my own admittedly limited experience I’ve found the reuse of code to wildly vary in terms of usefulness. Most of the actual work I do in a text editor these days revolves around forms and the scripts necessary to do something with them so I’m at least 89% talking out of my ass here but I’ve run into similar circumstances with larger chunks of code (like writing my own web server instead of just using whatever was rolled into a CMS) and liked it even less. In my current place of work there is a weird premium placed on the ability to do any programming work since we’re essentially in place as phone ‘bots and not expected to know a whole lot more than that. The fact that I can churn through a script that doesn’t really do a whole lot in twenty minutes is considered pretty valuable by some folks for reasons I can’t really figure out without chalking out a pentagram and summoning up some management types to explain things to me. […]

    pingback at 27. August 2006

  17. Seezar Honibe:

    Lets see if I got this right:

    1. Less is more
      Seems we all agree reuse is fiction. Reuse bloats the code and increases the chance for implementation and production errors. Don’t solve for an undefined problem - you cannot.
      Presentation correlation: If the business presentation were to address a different issue than for what it was created the presentation would confuse the audience.

    2. Consumers create
      As defined disposable software requires domain expertise. Focus on the problem to solve than being a tools expert. Most hardware products are all disposable and in some cases the factory that creates the specific hardware is also disposable. Here lies the rub; most consumers of the ’software’ are still not able to create their own applicatons.
      Presentation correlation: If I as the presenter need to deliver a board meeting, I would create my own presentation; not my assistant; not the IT guy. In fact what I lack in bling is made up for in focused content.

    3. Half-life matters ( http://en.wikipedia.org/wiki/Halflife )
      Knowing how long your application lasts determines how much effort you invest and I submit this defines disposability. Know that production support, network performance and interoperability as is lifetime usage are part of the specific requirements. But don’t code for more than you know.
      Presentation correlation: My presentations, created with PowerPoint, have a halflife of 7 days after which the information is out of date; the problem has been solved. However Microsoft PowerPoint is not at the same level of disposability as the presentation created with PP. That means software (C#) does not create disposability but specific application factories (PowerPoint) create disposable products (mypresentation.ppt).

      • did we not try and get here with 4GLs ;-)
    4. One size does not fit all
      What is being said about disposable applications is solve a specific problem and not all applications are solved in the sameway. The lifetime of the application may require different tools and different approaches. Ruby on Rails solves a specific class of problem and that is what makes RoR such a powerful factory. (DSL’s extend this metaphor)
      Presentation correlation: At some point I have to put aside PowerPoint and decided that a short video clip (also disposable) is the better presentation to get re-elected.

    5. Use common sense
      In the business world we constantly make value based decisions as to effort and result. As long as you know the lifetime value of your product you can match the implementation and maintenance effort appropriately.
      Presentation correlation: This is where I say maybe a verbal conversation or a blog entry is best and I throw away Microsoft PowerPoint and get back to doing real work, like walking my dog ;-)

    comment at 19. December 2006