Normally Ars Technica is one of my favorite web sites; they do strong, well-researched reporting and have good writers and editors.
But this recent article, which is getting a fair bit of attention, disappointed me greatly: How Microsoft dragged its development practices into the 21st century.
The author attempts to tell a story about changing development process approaches over the last few years, using Microsoft as his source of examples, and specifically uses the Visual Studio team in Microsoft as a focus of his discussion.
Avoiding any hard data, the article tries to use a narrative approach, spreading a wide net, touching on a vast universe of subjects, and dropping anecdotes spanning a 20-year time frame.
But the article fails on many levels.
It starts off poorly by making the classic mistake of trying to compare completely unrelated industrial processes, when clearly the author knows nothing about any of the industries and how they actually operate:
In industries such as manufacturing and construction, design must be done up front because things like cars and buildings are extremely hard to change once they've been built. In these fields, it's imperative to get the design as correct as possible right from the start. It's the only way to avoid the costs of recalling vehicles or tearing down buildings.
The design of cars, and the design of buildings, is in fact extremely iterative. Car designers and building architects use all sorts of tools (design sketches, scale models, 3d printers, computerized visualizations) to get all sorts of feedback during the design process.
Then he compounds his error by trying to compare completely unrelated types of software development, comparing the development of products like Windows, SQL Server, Exchange, or Microsoft office with an entirely different sort of software:
For example, lots of companies develop in-house applications to automate various business processes. In the course of developing these applications, it's often discovered that the old process just isn't that great. Developers will discover that there are redundant steps, or that two processes should be merged into one, or that one should be split into two. Electronic forms that mirror paper forms in their layout and sequence can provide familiarity, but it's often the case that rearranging the forms can be more logical.
Developing a custom in-house application, with users who are part of the same organization that performs the development, to solve a specific problem for that organization, has almost nothing in common with developing a general-purpose piece of software like SQL Server or Windows, which is used in all sorts of different environments, by organizations that have nothing to do with Microsoft, for all kinds of different purposes, by users who have never been, nor ever will be, Microsoft employees.
And a process that works for a 3 person team building an internal website has no hope of scaling to a process that allows 1,500 or more individuals to collaborate on an operating system used on several billion computers across the planet.
And the article descends into tragedy when the author reveals that he has never been part of a team that tried to build truly reliable software to address a truly complex project:
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.
I've worked on database servers, on web middleware, on networking protocols, on operating systems.
You start by carefully hiring the best possible developers you can find. You give them the best possible conditions you can provide (quiet environment, access to plenty of computer resources, meeting rooms to work out ideas cooperatively, excellent development tools to make them as efficient as possible).
You provide them with immense amounts of support: testing tools, hardware labs with test resources, testing experts, interaction designers, brilliant technical writers, and so on.
But even with all of this, building a product like SQL Server or Windows 8 is just HARD.
It's more than hard, it's nearly impossible.
If Microsoft manages to ONLY spend twice as long testing, stabilizing, and bullet-proofing their software as it took them to design and build it in the first place, I'm frankly astonished. I would have predicted 3-4 times as long.
And the fact that they can continue to roll out new releases of Office, of Windows, of SQL Server, every 2-3 years, on code bases that are nearly 3 decades old, with products that have to provide backward compatibility and upgrade paths for billions of users and existing installations, is a track record that nobody else in the industry can match.
Face it, software of this type is just fundamentally incredibly hard to build.
So while it's useful to look at alternate processes and techniques, and suggest things that might help improve the process, to walk up to a 25-year-old organization like Microsoft, who certainly have their faults, but who have figured out how to deliver an amazing stream of powerful and widely-accepted software, and then provide nothing but anecdotes and bad analogies, is just not what I expect of a publication like Ars Technica.
Maybe I totally missed the point of this article.
If so, drop me a line and tell me where I went wrong!
No comments:
Post a Comment