Microsoft and Software Engineering
Last fall, at the invitation of Visual Studio editor Patrick Meader, I wrote an editorial note on the subject of whether Microsoft products were enterprise-ready. After some thought, I concluded in the negative, not because of the products themselves, but at least partially because of the poor reputation of its own software development practices. "If Microsoft development teams use state of the art software engineering processes and tools, measure and manage risk, and adhere to their schedules," I said at the time, "the company needs to make this known, and make these processes and tools widely available as best practices."
Someone at Microsoft must have heard, because Russ Ryan, Product Unit Manager with the Visual Studio team, spoke in a VSLive keynote entitled 'How We Make the Sausage: Lessons from "the Factory Floor" on How Microsoft Does Software Engineering.' Because of my previous statements, I felt obligated to attend. That Microsoft was willing to discuss this topic in front of an audience of fifteen hundred software engineers was encouraging.
After listening to Russ, my impression is that Microsoft software engineering practices are no better than average, though trending better. Testing and fixing bugs were the big stories, but there were no state of the art software engineering practices, no research results cited, and no experimentation that could result in moving the industry as a whole forward. If this is representative of all Microsoft product groups, it was a disappointment that the company is not pushing the boundary of software engineering research and practice. If Microsoft cannot advance its own software engineering practices, what hope does the software industry have? I expect leadership from the leading software company, and it is clearly not there.
One positive note out of the session was the statement from Russ that "Superman doesn't scale." This, of course, refers to the stories of marathon coding and debugging stretches and rapid burnout among Microsoft coders. Acknowledging you have a problem is the first step to fixing it. But fixing a big problem isn't the same thing as being a leader.
Posted by Peter Varhol on 02/05/2006