Bosses of Bosses meeting with Bosses of Bosses

October 25, 2011 9:31 AM

I remember hearing an anecdote about the number of bugs a complex piece of software has (Windows Vista in this case?) can be correlated with the number of steps of communication between developers working on the project.

For instance, a worker getting info from his boss, who got that info from his boss, who heard it from another department's boss, who got their info from the subordinate of a subordinate...

I can't seem to find this online, but I'm also not sure what to look for.

Would anyone have anything to back the theme that uncommunicative hierarchy generally results in implementation issues? Documented anecdotes would be especially helpful.

posted by parallax7d to Work & Money (7 answers total)

You may be remembering something related in The Mythical Man-Month, a software engineering book from a few years ago that declared "adding manpower to a late software project makes it later" and focused on the fact that, beyond a critical point, the added productivity of a new engineer is matched or outpaced by the added difficulties in communicating with that new person; it popularized a cliche I now hear half my coworkers recite on a regular basis when asked if more people would speed up a development process: "Nine women can't make a baby in one month."
posted by Tomorrowful at 9:35 AM on October 25, 2011 [1 favorite]

Conway's Law
posted by cardioid at 9:48 AM on October 25, 2011 [1 favorite]

I doubt this is true. Requirements mis-communication is not generally likely to result in a "bug" per se. A bug is "HTTP proxy credentials don't get cached and so we prompt for them on every request to the web server". A requirements mis-communication is a lot more likely to manifest as something like "what, we were supposed to support HTTP proxies that require passwords? Nobody told me. It doesn't work because nobody built it."

It depends on how you define "bug", but "I built something that performs the wrong task correctly" and "I built something that performs the correct task incorrectly" are two different problems. The second implementation clearly has a bug (or several bugs) and the first implementation generally wouldn't be considered buggy, just wrong.
posted by tylerkaraszewski at 10:07 AM on October 25, 2011

There was a fantastic article/blog entry about the time that Vista came out over the hassles of changing the "shut down" button on Vista, how that went up through a hierarchy and series of build/test processes from the UI group over to the low level power management group in such a way that the time to develop the feature couldn't be less than 6 months.

I can't find it right now, but it was a great look at how compartmentalization of development processes that sliced the wrong way through a big project could make changes that you'd think would be really simple into major undertakings.
posted by straw at 10:22 AM on October 25, 2011 [1 favorite]

Response by poster: cardioid - that's fascinating and strikingly close.

tylerkaraszewski - no, i'm afraid it was something to do with software quality metrics, they found the only correlation to bugs was the number of hops between developers. I can see how this can can seem improbable for smaller software projects. I think they said it had something to do with the direction and practices the various bosses were following.
posted by parallax7d at 2:01 PM on October 25, 2011 [1 favorite]

It's mentioned in here.
posted by novalis_dt at 6:56 PM on October 25, 2011

Wondering if the anecdote has something to do with the "software Peter Principle" (although I'm a bit dubious about the framing of that article) and possibly an anecdote directly from Stev McConnell, a Microsoft developer and author of Code Complete. The unsourced text there -- doesn't appear as such in a web search -- is On average, 85 percent of a programmer's time is spent communicating with people, while only 15 percent is spent communicating with the computer. This seems a bit more on point than The Mythical Man-Month.

Or perhaps it's this somewhat infamous blog post, widely quoted in places like Slashdot.
posted by dhartung at 11:01 PM on October 25, 2011