Microsoft's market problem is self-evident: competitors like Google and Apple are turning out new products or versions every quarter. Microsoft has devolved to a twice-a-decade product delivery cycle, and risks losing credibility and market share to the more nimble competitors.
Microsoft's technology development problem is not so evident to the lay-person. Here's the gist:
- Developing a Microsoft OS version like Windows Vista requires more human effort than the entire Apollo man-on-the-moon project. There are between 5,000 and 10,000 technicians working on the Vista generation, which by my count includes 13-15 specific products. Think 50,000 person-years to get the Vista generation out the door. This scope of effort make building the pyramids seem like a child stacking blocks.
- Microsoft hires the best and brightest. These folks want to do things their own way, not be rigid automatons with no freedom to innovate. Mistakes are made. Poorly written code is dropped into the day's "build" and doesn't work. Thousands of co-workers the next day cannot see the integration of their own efforts put to work. Project delays build, and a year or two of overtime, nights and weekends becomes de rigor. Burnout occurs fast in this environment.
- Windows lacks a solid architecture and certainly not a modular one. Modularity would allow Microsoft to plug-and-replace modules with new features. Modularity would certainly speed time-to-market. It might also make certain technology areas incluing security easier to deal with. Think this was not a problem? The Wall Street Journal says a flowchart of how Windows fits together was 8 feet tall and 11 feet wide.
I am pleased Microsoft has cast off its evil ways because it will be a lot easier to innovate in the future from a shear programming standpoint. But I have to say I told you so. I recall an evening discussion with Jim Alchin in 1997 at Bill Gates' house. We were drinking scotch. As an ex-programmer and systems integration program manager, I asked Alchin how he could manage the 5,000 programmers then cranking away on Windows 2000, whether Win2K would ever get done, and how bug free would it be? I was in awe that it could be done the way Microsoft was going about the effort. He said they were confident the project would complete in 1998 and that the system worked because Microsoft could afford to use brute force. Well, Jim Alchin, whom I deeply respect, was wrong.
As Jim Allchin gets ready to retire next year, he can be sure that the changes begun last year in development methodology and process will be enormously beneficial to the company going forward.
Lesson Learned: Brute Force is Not Scalable or Sustainable.
No comments:
Post a Comment
All comments are moderated.
Note: Only a member of this blog may post a comment.