ComputerWorld.com runs an interesting piece, Five Web 2.0 App Dev Lessons for Enterprise IT, this week by Heather Havenstain about how an agile approach to application development permits an almost constant evolution of feature sets that are in line with users’ needs and suggestions. Dynamic scripting languages like Ruby, Perl and Python (sounds like a hoochie-coochie act at the 1908 Chicago World’s Fair, don’t it?) short-cut long lines of code, letting developers be faster, more creative and more flexible with their work. ‘Permanent beta’ the article calls it.

The ComputerWorld article underscores yet again how vital improvisation is to business in the Networked World — after all, what is improvisation if not ‘agile development’? The article also shows how ‘performance’ in business does not refer solely to folks standing up and holding forth in front of other folks. Apps are performance for an audience, too. The Five App Dev Lessons cited by ComputerWorld are straight from the improvisers’ playbook. Here they are. Our comments are in italics:

1) Break the barrier between developers and end users, and involve users in quality assurance processes. Like all good improvisation, agile development begins with suggestions from the audience. When users become players in your game (e.g. QA processes) they are much more likely to have a rooting interest in your performance (e.g. remain loyal to your brand).

2) Keep it simple. Poorly improvised business scenes often get sabotaged by too much extraneous information. That includes the development of apps with functionality that 99% of your audience doesn’t want or care about. If two players are performing an improvised theater scene set on their wedding night in the car on the way to the airport for their honeymoon…and they toss things into the scene like ‘her mother’, ‘his love of baseball’, ‘what happened at the reception’ and ‘who makes them jealous’…that is going to be one unwieldy and not very compelling scene. But that’s exactly what a lot of apps are like. “Feature Creep” is a horror movie we’ve all sat through.

3) Stick to the script. Okay, right, we know, sticking to a script is the opposite of improvisation, but CW is referring to dynamic scripting languages that, according to a recent Forrester study, can cut development time by 30-40%. Anytime the window between when you think about something (functional specs) and when you can do it (release date) closes, you have become more improvisational.

4) Release early and often. Many agile developers update their apps several times a day (the article cites Wesabe, a San Francisco-based money management site as one of these; Mixx.com, a social news site based in MacLean, VA, as two such developers). Think about yourself as being ‘in the audience’ for money management and social news apps: Are you more likely to applaud a site that evolves organically based on your suggestions, or one that announces upgrades periodically but with lots of fanfare, in the MS Explorer style? In cloud computing land, versioning seems stodgy and unresponsive compared to continuous, audience-minded tweaking.

5) Let the users, not the developers, determine new features. We would amend this slightly to read “Let users and developers working in collaboration determine new features.” The spirit of the tip is correct — take suggestions from your audience — but developers know things that users cannot, and vice versa. The collaboration between developer and user should no more discriminate against a developer’s idea than it should against a user’s. And hey, not every idea from every boss’s wife is automatically a bad one. Stay open to where the good ideas come from, because they can come from anywhere.

P.S. A commenter on the article, a guy named ‘Grant’, notes that the ‘agile development’ described by Havenstein is nothing new, and has been around for a couple of years. He rejects the idea of branding any app a ‘Web 2.0′ thing. Grant has a very good point, not only about the concept that there actually is no such thing as a ‘version 2.0′ of the Web, but also about versions generally. With agile development, versioning loses meaning. Versions of apps are like the same movie with many remakes. An agile app, by contrast, is one long neverending movie. An agile app never repeats itself, while versions repeat themselves all the time. Another advantage to agile development over versioning: Users have for too long been forced to pay for versions of software that are either way overbuilt or mostly cosmetic. With cloud computing and agile development, that game is changing in a hurry. Why should I care what version of an app I’m using as long as it does what I need it to do, and enables me to work today more productively than I did yesterday?

Tags: Agile Development, Application Development, Cloud Computing, Computerworld, Feedback, Heather Havenstein, Networked World, Quality Assurance, Suggestions From the Audience, User Suggestions, Web 2.0

This entry was posted on Tuesday, July 22nd, 2008 at 5:52 pm and is filed under Entrepreneurship, Innovation, Networked World, Speed, Suggestions From the Audience, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.