IT's lessons to be learned from Web 2.0 developers

Companies can cut costs and boost productivity by focusing more on their users.

Yahoo Inc.'s Flickr unit reported that the latest update to the photo-sharing Web site went live two days earlier with five changes made by two of its developers. The July 12 "deployment" was the 42nd new release in a week where 19 developers made 735 changes.

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

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 start-ups.

The new process, which some champions call "application development 2.0," contrasts 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 significantly cut development costs and improve software quality if managers and developers are willing to make some hard changes.

"Sometimes enterprise organizations 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 Inc. "That is not the case. They have built discipline into the process that allows them to be very reactive -- a [good] lesson for IT organizations."

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 Web 2.0 development processes. Here they are:

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

Wesabe Inc., which runs a personal finance Web site, doesn't have a formal internal quality assurance group. Instead, the San Francisco-based company relies on users and founder and CEO Marc Hedlund.

Wesabe's developers work with users to come up with new features, and then Hedlund tests them before rolling them 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 people who use their applications. Direct user complaints or compliments are far better motivators for developers than PowerPoint slides with bar charts representing user desires.

William Gribbons, director of the graduate program in human factors at Bentley College in Waltham, Mass., said that large companies can 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 lead to increases in 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, Gribbons suggested.

2. Keep it simple.

Although 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 realize, can be obstacles, problems. The more powerful an application is, the more specialized 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 just one way, Gribbons noted. But without constant interaction with users, developers are often 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's Java or Microsoft'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 they could 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.

4. Release early and often.

Wesabe, like Flickr, updates its site often, usually several times a day. The constant interaction with users provides Wesabe developers with almost immediate notification of bugs, Hedlund noted.

In addition, Wesabe and many other Web 2.0 companies run so-called shadow versions of their sites, which help determine how users respond to specific feature updates. A report compiled by the shadow site could show, for example, how often users log off the site or whether the amount of financial information uploaded by users has dropped.

Recommended Reading Inc.'s Mixx.com social news site, which allows users to submit and rank news items, is also updated far more often than traditional IT applications -- about once every week or two, said CEO Chris McGill.

In fact, "long term" for Mixx means a product road map that stretches out only six months, said McGill, who founded the McLean, Va., firm in 2007 after stints as general manager of Yahoo News and vice president of strategy at Gannett Co.'s USA Today newspaper.

The Mixx.com development team, which meets daily to discuss the previous day's work, uses the Scrum agile development method.

5. Let the users, not the developers, determine new features.

Top Internet companies like Amazon.com Inc. and Google Inc. release new features to small subsets of users and then compare their feedback to the experiences of control groups. The companies say the method provides much better validation for new features and products than customer surveys or even discussions between users and product managers.

Mixx.com hopes one day to follow the same process, McGill noted, adding that it has already moved to take advantage of a community formed by its users. Mixx uses the community as a "24/7 focus group" to bounce ideas off its members, he added.

Shifting opinions
Although most large companies are unlikely to flock quickly to Web 2.0 development techniques -- and some applications would not be a good fit for this methodology, observers acknowledged -- some are starting to realize the merits of these new processes. That's the message of a July 1 survey of more than 1,300 developers that Glastonbury, Conn.-based TopCoder Inc. conducted for Computerworld.

In the survey of developers taking part in a recent TopCoder online coding competition, an overwhelmingly majority (70%) of the respondents said that traditional corporate development teams could benefit from Web 2.0 techniques, specifically the incremental feature releases, quick user feedback loops and quality assurance programs that include users.

What's more, 57% of the respondents said that problem-solving and analytical skills will be key requirements for next-generation developers, while 18% cited the need to work with online communities. Meanwhile, 24% said that code generation is the key long-range development skill.

Gribbons said that corporate use of application development 2.0 techniques -- especially the focus on the user -- could be critical to reducing the number of IT development projects that are scrapped before completion.

As he pointed out, "no other industry would accept a failure rate that we have in our industry."