This article provoked a lot of discussion about software development and architecture where I work.

With a few more weeks for managing the transitions between the phases of development, some extra time for last-minute fixes to both the beta and the final build, and a few weeks to recover between versions, the result was a two-year development process in which only about four months would be spent writing new code. Twice as long would be spent fixing that code.

For me, this paragraph sums up where multi-year release cycles are just plain wrong:

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.