Microsoft's mythical man-years

The company boasts that it's making Herculean security efforts -- but throwing more people at software problems rarely solves them.

By Scott Rosenberg

Apr 12, 2002 | The claim was, let's just say, a little arrogant, a little overconfident, in the way the world has come to expect from Microsoft. It came at the end of a New York Times article about the company's big new push to make its software more secure.

"I'd be astonished," said Steven B. Lipner, Microsoft's director of security assurance, "if the open-source community has in total done as many man-years of computer security code reviews as we have done in the last two months."

What Lipner was saying, with that Microsoft swagger, was simple: Microsoft has rallied its massive army of smart developers under the banner of "Trustworthy Computing" and turned their overpowering force on its security problem -- the plague of Internet-borne viruses and worms that afflicts many of its products. The problem, like one of Microsoft's competitors, is doomed. No other force on earth -- certainly nothing as puny as a ragtag bunch of volunteer programmers contributing code fixes cooperatively -- could possibly match such might. Die, worms, before the wrath of Gates!

It sounds intimidating. Only, to anyone with a long memory in the software field, the term "man-years" should set off some alarms.

Technically, Lipner is saying the following: Let X equal the number of individual Microsoft programmers reviewing its products' security, multiplied by the amount of time each has spent on the task. Let Y equal the number of open-source programmers reviewing their software's security, multiplied by the amount of time they have spent on the task. X is way greater than Y. All this rings with the kind of scary precision that cows nontechnical people when they hear it in engineers' voices.

The trouble is, the whole concept of measuring software productivity in "man-years" or "man-months" is profoundly discredited -- and not by some radical new theory of software development, but in what is probably the single most seminal work on software management: Frederick P. Brooks' "The Mythical Man-Month," first published in 1975, when Bill Gates was a stripling and personal computing a dream.

Brooks was an IBM veteran who'd watched Big Blue's mainframe software projects spiral out of control in the 1960s. As he analyzed the company's epic failures -- which earned the label of "software crisis" in their day -- he discovered a counterintuitive principle: "Adding manpower to a late software project makes it later."

How can that be? Brooks argued that, with most common large-scale software projects, adding manpower to a team results in further delays, as veterans stop to introduce newcomers to the complexities and challenges of the project, and as managers step back to divide up the work afresh. When a team is behind schedule, throwing new people at the problem actually makes the problem worse. Brooks concluded, "The man-month as a unit for measuring the size of a job is a dangerous and deceptive myth."

While most aspects of the software business have changed since 1975, and good practices have helped many development efforts skirt the kinds of disasters Brooks observed at IBM, the general validity of his observation remains unchallenged. Which might leave you wondering what a Microsoft manager is doing, in 2002, boasting about how many man-years his company is throwing at its current top-priority project.

One answer is that Microsoft today is desperately trying to win back its customers' trust -- and that, while software experts may understand Brooks' principles, the business managers who are Microsoft's customers may be comforted by the thought of that busy hive of developers, pumping out their man-years of code review.

Next Page: Why Microsoft's "more man-years" claim is "absolute crap"

• View blog reactions