Five Web 2.0 developer lessons for enterprise IT

The perpetual beta of the Web 2.0 world has a lot to offer enterprise developer teams.

Share

Yahoo 's Flickr unit reported on the afternoon of 16 July that the latest update to the photo sharing Web site went live just before 5 p.m. with 9 changes made by three of its developers. The "deployment" was the 36th new release in a week where 627 changes were made by 21 developers.

Such constant tweaking - called a perpetual beta in the Web 2.0 world - is common for companies like Flickr that build applications for a consumer market that's always in flux.

The quick, incremental updates, along with heavy user involvement, are key characteristics of an emerging software development paradigm championed by a new generation of Web 2.0 startups.

The new process, which some champions call application development 2.0, contrast markedly with the traditional corporate waterfall process that separates projects into several distinct phases, ranging from requirements to maintenance. Nonetheless, application development 2.0 could bring significant benefits to corporate IT shops if managers and developers are willing to change.

"Sometimes enterprise organisations tend to look at these [Web 2.0-focused] places and say they are not very disciplined," said Jeffrey Hammond an analyst at Forrester Research "That is not the case. They have built discipline into the process that allows them to be very reactive -- a [good] lesson for IT organisations.

Based on interviews with analysts and executives of Web 2.0 firms, Computerworld compiled a list of five ways that corporate IT managers can benefit from using Web 2.0 development processes. They are:

1. Break the barrier between developers and end users, and involve users in quality assurance processes.

Wesabe , which runs a personal finance Web site, doesn't have a formal internal quality assurance group, instead relying on users and founder and CEO Marc Hedlund.

Wesabe's developers work with users to come up with new features, and then Hedlund tries to break them. If he fails, the features are quickly rolled out to wesabe.com.

Hedlund said that before launching Wesabe two years ago, he studied many of the common development techniques put into place by Web 2.0 companies. He said he concluded that applications are inherently built better when developers are not insulated from the users of their applications. Direct user complaints or compliments are far better motivators for developers than a screen in a meeting room displaying faceless bar charts listing user desires.

William Gribbons, director of the graduate program in human factors at Bentley College in Waltham, Mass., said that large companies could benefit financially by using Web 2.0 techniques to develop applications for employees.

"Companies often think their [internal] applications are different because they're used by employees [who] are compensated for the pain and suffering they are enduring," he said. That pain and suffering, however, can boost training costs and employee turnover, and cut productivity - all a hit to the corporate bottom line.

Corporate development teams should focus on close interaction with internal users to gather requirements, and to create a controlled, systematic way to observe users interacting with prototypes, he suggested.

2. Keep it simple

While many consumer-focused Web 2.0 applications may seem simple, that simplicity is usually the result of hard work by developers working hand-in-hand with users.

Stan Schroeder, a blogger at Mashable, a social network that follows Web 2.0 companies, noted in a post that developers have begun to understand that it's better to build a very simple service, and then add APIs to provide complex services.

"Features, I've recently come to realise, can be obstacles. Problems. The more powerful an application is, the more specialised it is, and thus with increased power its intended audience shrinks," Schroeder wrote.

Many times traditional enterprise IT shops will identify a need and develop multiple ways of meeting it when the user would be happy with one, Gribbons noted. But without constant interaction with users, developers often are unaware of the yearning for simple user interfaces.

3. Stick to the script

Web 2.0 companies are partial to dynamic scripting languages like Ruby, Python, Perl and PHP, finding them better choices for their projects than Sun Microsystems 's Java or Microsoft Corp.'s .Net.

Forrester's Hammond noted that once developers become proficient in one of the dynamic languages, they can build new applications quickly - 30% to 40% faster than with Java or .Net.

More than half of all North American developers are using scripting languages to some degree, according to a December survey by Evans Data Corp., a Santa Cruz, Calif., research firm.

While more than half of those developers now use scripts less than 20% of the time, both the total number of developers using scripting languages and the amount of time spent will likely increase over the next year, according to the Evans survey.

Find your next job with computerworld UK jobs