My G+ Profile
« RedHat's JBoss Acquisition is a Done Deal | Main | v|100 Luncheon »
Evolving Software
Jon Udell’s latest column at InfoWorld is a scary story that’s all too common: fork-lift upgrades of Web-based software that leaves users worse-off than before.
I’ve been consulting with a company that’s developing a Web-based product for the last five or six months. The back-end is, realistically, quite complex and involves a fair amount of ontological work. I’ve suggested a release strategy that gets a timely and useful piece of the product out soon and then adds functionality little-by-little, every week or so, over the coming months.
You’d be surprise by the amount of resistance that sort of idea attracts. Not by management either—they seem all too ready to take an incremental approach. Interestingly, most of the resistance comes from programmers in the trenches. I’m not sure why.
Still, as Jon suggests, the steady accretion of small, incremental changes combined with continuous evaluation of the effects of those changes is the key to systems that evolve and is the strategy most likely to win.
Posted by windley on June 5, 2006 11:03 AM
Comment from Peter Abilla at June 5, 2006 5:23 PM
It sounds like those engineers haven't bought-in on the Rational, eXtreme, or Agile methodologies -- these methodologies are pretty much standard now and all of these are completely against the "Waterfall" approach to software engineering, but instead focus on the Iterative process instead. It sounds like ignorance is the root cause of those engineer's resistance.
Comment from Dr. Bonzo at June 6, 2006 12:22 PM
In my shop, the source of that resistance is a two-fold fear on the part of the developers.
One fear is that the users (the target audience) won't tolerate a series of frequent, small changes to the application. The developers (encourage, frankly, by our equivalent of sales-and-marketing folk) believe that "the users" will resist any change at all once the application goes live -- so it'd better be "perfect" at first release.
The second fear is the developers' dread that they might have to repeat work they've already done. (Or, equivalently, have to throw away otherwise perfectly good code in order to introduce or enable the new functionality.) Basically, we none of us want to think that *any* of our time has been wasted, no?
With regard to the second objection, my experience has been that we end up wasting far more time bickering about trivia in the effort to get things "perfect" the first time than we would by quickly coding a prototype (or two) and having to throw it away altogether.
With regard to the first, I find that it's quite possible to spend so much time waiting for the "harmonic convergence" of team structure, resource availability, and user input that by the time the app goes live, "the users" have gone somewhere else to get their needs met.