How Microsoft Develops Its Software

crem_d_genes writes "David Gristwood has a post on his blog that notes '21 Rules of Thumb - How Microsoft Develops Its Software', on which he will elaborate at TechEd in Amsterdam next week. It was derived from interviews with Jim Mccarthy, also of Microsoft. Gristwood: 'As someone who has been involved with software development for over two decades, the whole area of how you actually bring together a team and get them to successfully deliver a project on time, is one worthy of a lot of attention, if only because it is so hard to do. Even before I joined Microsoft, ten years ago, I was interested in this topic, having been involved myself in a couple of projects that, I shall politely say, were somewhat less than successful.' Tips include such features as 'Don't know what you don't know.'; 'Beware the guy in a room.'; 'Never trade a bad date for an equally bad date.'; and 'Enrapture the customers.'"

Comments

on what?

[gmack]

"the whole area of how you actually bring together a team and get them to successfully deliver a project on time"

When was the last time Microsoft actually delivered a product on time?

Really?

[Dagny Taggert]

'Don't know what you don't know.'; 'Never trade a bad date for an equally bad date.'; and 'Enrapture the customers. Hasn't Microsoft violated every one of those rules, even recently? I'm not trying to be flippant. I just can't take a symposium on software development held by MS very seriously. What I would really, really like to see is a conference in which some developers from MS discuss how they deal with damage control on a daily basis. I think that would drum up some interest.

Re:My post

[LittleBigLui]

It usually is the other way around.

Are you from soviet russia?

How Microsoft Develops Software...

[The Lynxpro]

One word: poorly.

My writing didn't require a wordy article to get to the kernel (pun intended) of truth. Perhaps the other author is paid per word printed.

Re:What's with #6?

[babbage]

Did you actually read the point that you're getting all worked up about? Here, let me repeat it for you, with added emphasis here and there to make it easier to grasp:

6. Beware of a guy in a room.

This is really just a special case of "Don't go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.

There are many pathologies at play here as well as certain healthy patterns of creative behavior. One pathology is a type of savior complex that cannot be satisfied without blowing every single deadline but the last, and then emerging victoriously with a brilliant piece of work five minutes late. A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.

Random observations:

• He says to beware of the guy in the room, not avoid or curtail him. He concedes that some talented programmers will be more creative when left to their own devices, but warns that more often this kind of behavior is a risk.
• He presents this as a subset of the don't go dark rule, which basically just says that a non-communicating team is a dysfunctional team. This shouldn't be a controversial assertion, and it should be obvious that isolated developers are a subset of this dysfunction.
• He warns that while these isolated geniuses can develop great work, they generally aren't doing it in the context of a structured, scheduled development team. Generally. It can happen, and he allows room for it, but he's saying that these lone geniuses need at least some supervision in order to keep everything on track.
• He describes the dysfunctional variant of the lone genius as having a savior complex, who will let everything fall apart until the last minute, at which he will pull the rabbit out of the hat just past the deadline. I've worked with this guy; it's extremely stressful for all the other staff, and is not the sort of behavior that should be encouraged. He contrasts this with the guy that is a true innovator who is putting so much of his effort into his work that he has nothing left for distractions like teamwork & meetings.

While this latter kind of isolated-yet-healthily-constructive behavior is indeed a good thing -- and is obviously what you're sticking up for -- my hunch is that these guys are a lot more rare than they think they are. Moreover, my hunch is that this healthy form of solitude can tend over time to turn to the unhealthy & unproductive variety without at least some supervision & interaction with peers.

So, the title he gave -- "beware of a guy in a room" -- about sums it up. It's not to say that the "guy in a room" can't do good work or be an effective member of a large software development effort. Rather, he's pointing out that there's several possibly unhealthy factors going on with such behavior, which lead to a fine line between how successful or otherwise such a person will be as a member of such a development group. It is the job of a software development manager -- who is, after all, the target audience for this essay -- to be attuned to these factors and make sure that the lone geniuses on their teams are tending towards the productive end of the spectrum rather than the dysfunctional end.

What's so controversial about that?