Agile Development Success Story

Pioneers In Agile Development

Eric N. Shapiro, ArcTouch’s CEO, is one of the earliest adopters of agile software development. In the early 2000s, he brought a form of agile development called Extreme Programming to Zero G Software, his prior company. It successfully changed the company and led to better products, with fewer defects, delivered on schedule.

His agile development success story was profiled in the MIT Technology Review in November 2003, and after the successful roll out at Zero G, Eric is credited with helping to bring agile development to some of his customers, including IBM and Novell. He is now leveraging those same agile development “best practices” in ArcTouch’s process for rapidly creating custom apps for the iOS, Android, BlackBerry, and other leading mobile platforms.

Extreme Programming: The Zero G Experience

How a software company saved itself by overhauling its development process – and trusting its engineers’ instincts.

By Claire Tristram

MIT Technology Review – November 2003

Zero G is a survivor. The San Francisco company makes installation software-the programs that run when you’re putting new software on your PC. Its headquarters are in the once booming south-of-Market area, where it has remained happily profitable even as its former dot-com neighbors have disappeared. But it almost bit the dust along with them, says president and cofounder Eric N. Shapiro-not because of the economy, but because of the slapdash way it wrote software before adopting a methodology known as “extreme programming.”

The change came not a moment too soon. Until last year, Zero G-like many software companies-followed a six-month cycle for developing new releases of its products, with marketing handing the engineers a list of features, and the engineers agreeing to transform them into software code by a certain date. According to Shapiro, at the beginning of the cycle, engineers would cherry-pick the features that looked the most fun to program, rather than those most important to the customer. Consequently, in early 2002, as the May ship date for Zero G’s release of its InstallAnywhere software grew closer, company programmers found themselves working 15-hour days to complete all the required features, even as the marketing department tried to foist new requests on them. The programmers heroically coded one fix after another, only to find that each fix broke something else. The bug list grew longer every day.

The result? “It was the worst product we ever shipped,” says Shapiro. The release was not only buggy, it was booby-trapped. Disaffected engineers had revolted, adding features of their own, including a hidden routine-known in the industry as an “Easter egg”-that caused customers’ monitors to go black on April Fool’s Day. Predictably, the self-sabotage led to a barrage of customer service calls, not to mention lost accounts.

Shapiro recognized that the future of his company depended on its doing better the next time. And with remarkable foresight, he realized the problem lay not in his people, but in the development process itself. Rather than blaming his engineers, he decided to test the extreme-programming methodology, which at its core is about relying on software engineers’ instincts about what works and what doesn’t, and which had been gaining a rabid following among developers who had tried it and found that it worked.

“I had the idea in mind of taking everything good about software and cranking it all the way to 10,” says programming guru Kent Beck, who began developing the concept of extreme programming while consulting for Chrysler in 1996. “All the stuff that programmers are naturally suspicious of, we’d not do at all.”

If testing is a good thing to do, for example, then test all the time. If programmers are suspicious of long development cycles, then break the long cycle into chunks that are as short as practically possible-say, two or three weeks, each culminating in a modest goal that engineers can commit to, knowing they will meet it. If frequent code reviews are helpful, then review continuously, having programmers work in pairs and check each other’s code as they go. If programmers complain that customers keep changing their minds, then plan for customers who change their minds: the shorter cycles allow wholesale revisions every few weeks, when a new cycle begins and new goals are set.

Zero G’s results have been dramatic. Shapiro says that the company’s latest version of InstallAnywhere-written entirely using the extreme-programming methodology and released last May-packs much greater functionality than the May 2002 version in fewer lines of code, and comes without any Easter eggs. Morale is up, too. People like their jobs again.

“In the traditional way of doing things, developers get a long list of features and a long timeline,” says Shapiro. “By the time the software is done, customers have changed their minds. With a two-week development cycle, we’re able to respond. We don’t have to be geniuses.”

Extreme-Programming Precepts

Like a 12-step program with its inspirational prayers and mottoes, extreme programming has its own list of commandments for software developers.

A selection:

• Do the simplest thing that could possibly work. If a program is so complex that it will be hard to modify later, it is just too complex.

• You’re not gonna need it. Save time by implementing new features when you actually need them, not when you foresee that you’ll need them someday.

• Code reviews are good. Programmers should work in pairs, sharing one screen, so that all code is reviewed as it is written.

• Interaction between developers and customers is good. Have a customer on site who can prioritize work for the team and answer questions as they arise.

• Work at a pace that can be sustained indefinitely. Work overtime only when it is effective. “Death march” projects do not produce quality software.