Part 1

Grim, but more or less effective

This process was far from ideal. Consider, for example, what happened when a Visual Studio user installed the beta and a month later found and reported a bug. It was probably too late for anything to be done about it for that release. By the time the bug had been filed and validated, the development process was nearing completion. If the bug was serious enough, it could be addressed in the stabilization phase, but in most cases it would be left unfixed, perhaps for inclusion in the next version.

If bugs slipped through to the release version, they risked not being scheduled for a fix for years unless they were reported very quickly—within the lengthy planning and design stage. Telling customers that their issue would be fixed in three years doesn’t make for a healthy relationship.

Bugs weren’t the only issue with this kind of process. For example, after years of stagnation, the C++ specification is now being regularly updated with a mix of updates to the main spec itself and smaller specs called Technical Specifications (TS). (TSes add new capabilities in more focused ways; for example, there are TSes in development for networking, filesystem access, parallel programming, and so on.) Over the next couple of years, eight or more of these TSes should be finalized.

Their release isn’t synchronized in any way with Microsoft’s development cycle. For the two-year product cycle to be able to easily incorporate specs like these, the spec has to be reasonably complete, if not entirely finished, in time for the planning stage. If it misses that planning stage, it’s too late for a particular product cycle and has to wait 18 to 24 months for the next planning stage, and then another 24 months for the next release.

The entire development approach left Visual Studio doomed to be perennially out of date and behind the times.

In addition to making the Visual Studio team enormously unresponsive, this development approach wasn’t much good for team morale. A feature developed during the first development phase wouldn’t properly get into customer hands for the better part of 18 months. For Windows and Office, with their three-year cycles, the effect is even worse. A developer could be waiting more than two years before the work they did would ever make it to end users. Most developers actually want their software to be used; it’s just not that satisfying to know that you’ve implemented some great new feature that nobody will actually use for years.

With Microsoft’s long development cycles, a developer may not even be on the same team—and may not even be at the company—by the time their code makes it to desktops.

The development structure has a similar effect. Spending just four months writing new code and the rest of the time working through a vast backlog of bugs isn’t any developer’s dream.

And then the world changed

For all these problems and challenges, Microsoft has nonetheless been tremendously successful as a software developer. Before the rise of the World Wide Web, these infrequent releases, troublesome as they may have been, actually made a lot of sense. In those days, distributing software meant shipping out a bunch of floppy disks or CDs and enduring a tedious installation process. Limiting this process such that you only had to suffer through it every few years was not a bad thing, and the waterfall process, or some close approximation to it, was a software industry norm.

However, it wasn’t the only development process around, and the rise of the Web has pushed other approaches to the foreground. Web applications change the software delivery model in some important ways. Most significantly, they take “installation” out of the equation. While the application developer does have to deploy updates to servers, end users don’t have to take any action. They just visit a site and discover that its appearance or functionality has changed since their last visit.

This also makes some things that are tricky or annoying to do with traditional software very easy. A Web application can roll out new features or designs to a minority of users to gauge the response and verify that they work and then either roll back the feature or give it to everyone, depending on the reaction. A/B testing to compare the efficacy of competing designs is also straightforward. As a result, it’s a lot easier for Web developers to quickly collect usage data and make decisions based on that data.

They also changed the prevailing pricing model. Instead of buying a perpetual license every three years, users of Web applications either pay nothing (because the application is ad funded) or pay an ongoing subscription. While shrinkwrap software tends to “need” substantial differences between versions in order to justify a slew of new upgrades, Web applications have no corresponding incentive to ship only major updates. Incremental updates and piecemeal improvement are just as effective.

These features of the Web make the waterfall process particularly inappropriate. Fortunately, the waterfall process isn’t the only one that’s out there these days. As the Web rose, so too did Web-suitable development processes.

Agile development for a changing world

The adjective that’s used to describe these processes is “agile.” There are many different agile development processes, but all retain certain common features. Fundamentally, agile processes are designed around short development cycles, iterative improvement, and the ability to easily respond to change.

Iterative development processes of one kind or another have been around for almost as long as software development itself. The kinds of practices that have come to be known as “agile” proliferated in the 1990s, and the “agile” label was codified in 2001 when a group of developers published the “Agile Manifesto,” which reads:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more. “

Agile development tends to require a lot of institutional buy-in. The old waterfall approach of writing a big spec, everyone signing off and agreeing on it, and then some months later a finished piece of software popping out of the compiler is comfortable. Particularly in the line of business and similar applications, it allows the person or company who is commissioning the application to end their involvement after the design and specification stage. When that development is outsourced, it provides a straightforward benchmark against which contractual performance and adherence can be measured: does the program meet the mutually agreed specification or not?

Similarly, stacks of documentation are reassuring. Documentation and specifications both tend to feel concrete in a way that, to non-developers, software often does not. How can a customer know that a software company has written the software it asked for if there is not documentation to prove it?

With agile processes, these specs and docs are deprioritized, if not abandoned altogether. Customers or users tend to be regularly involved with the development process, using the software as it is incrementally developed and delivered and providing regular feedback.

The advantages of agile development contrast neatly with the disadvantages of waterfall development. Practices vary, but a development cycle in an agile team will typically be in the range of two to four weeks. While development teams can still have a longer outlook—things they’d like to do in the next six months, year, perhaps even longer—the planning and specific development priorities are handled at a much smaller scale, and this makes them much easier to change.

The result of each of these short iterations should be something that is more or less usable. Though major features will likely need to be divided into multiple iterations, each incremental version of the software should nonetheless be usable. This in turn makes it much easier for feedback to be delivered. Perhaps the layout of a screen is awkward; perhaps the feature doesn’t quite do what people expected it to do; perhaps there are bugs. In any case, testers and users alike can react to what they see and have before them and tell the developers accordingly.

The short timescales in turn enable the developers to actually respond to these demands.

Part 3

Source : arstechnica.com