Slashdot Mirror
Software Engineering at Microsoft
an_mo writes "A link to a google cached document is floating around some mailing lists containing some info about microsoft software engineering. In particular the document contains juicy bits about the development of a large project like NT/2K. Some examples: Team size went from 200 (NT3.1) to 1400 (Win2k). Complete build of win2k time is 8hrs on 4way PIII and requires 50GB of hard drive space. Written/email permission required for checkins by the build team." The HTML version on Usenix's site is much nicer than Google's auto-translated version.
Show-Stopper!: The Breakneck Race to Create Windows Nt and the Next Generation at Microsoft by G. Pascal Zachary
very funny about the head guy throwing chairs out of windows ( the phyical ones ironic really )
and the black team....
read it and Mythical Man-Month, and then you might have a small background
regards
john jones
Guys, the PowerPoint slides for the Lucovsky presentation has been publicly downloadable for almost 2 years. I always find it sad when Slashdot reports something old as something new.
h tml
Go get the slides at http://www.usenix.org/events/usenix-win2000/tech.
I venture to guess, however, that your company is somewhat smaller than Microsoft, is held together by shared enthusiasm and the exilaration of short term releases, and that you don't face many of the problems that any large company, not just the Borg, does. I would never defend the quality of MS products but anyone who has worked on large products with many existing custoemrs in a large software company like an Oracle, Microsoft or IBM will understand that it is simply impossible to only hire expert programmers whose work never needs to be checked by anyone else and who don't need any supervision.
Some of your other statements are rather sweeping. Some parts of UML - such as object modelling - are very useful indeed and can act as highly rigorous sources for a lot of code and database generation or automated access. Others (like Use cases IMHO) suck and are of little use to programmers, though more in communication with PHBs and business types.
A lot of what you say is very true for small focused teams working in their bedrooms/garages/garretts but much less so for any large software developer who sells software for money. Your "expert-driven" approach would never work at a Microsoft.
Your last point, that OSS produces better results, is probably true. Certainly its more cost-efficient. But does it produce profitable companies that make heaps of money ? Maybe you don't like the idea of that. But most of the rest of the world, including your gray-haired neighbour who plans to retire on the proceeds of his portfolio, does.
[x] auto-moderate all posts by this user as insightful
UML and other modelling fads. My former employer required the use of 65-page UML diagrams for the simplest command-line utilities. Why? Because it was popular, and the investors liked to make sure we were buzzword-compliant. UML is designed for non-technical audiences, and as such it flies in the face of the engineering goals it is designed to solve.
I've found UML, or at least quasi-UML, useful; any time I design a system I draw a quick UML sketch just to help me think about what's invovled. Unless, that is, it's something really dead simple .. something equivalent to a homework assignment. Sometimes most of the really hard work goes into a good UML diagram, and the rest becomes easy.
But despite this, I can't help but reflect on your statement in utter horror. What the hell kind of UML diagram does one put together for, say, ls? Or cd? Or a numerical calculation?
Code review. Code review is a power trip and best, and a drain on morale at worst. If a programmer cannot be trusted to develop excellent code, he should be replaced with somebody who can. It's a tight labor market on the developers' side, so incompetent programmers should be spending their time reading O'Reilley books instead of playing games and looking at porn in their parents' basement.
I disagree with you on two fronts. One, I've always found code review beneficial for a project. Weaker coders learn good habits; stonger coders teach good habits; bugs not visible to some become visible to others; the general quality of code improves. People who can't deal with constructive criticism of their code make for bad team-mates.
Secondly, I've never met anyone who became a good programmer by reading books, even books as high quality as O'Reilly's. I learned to code by writing code and reading others' code. The books make handy references, but sticking to books is akin to trying to learn to write well by reading the dictionary.
Large, geographically concentrated development teams. The best work is emphatically not done by 1400 people in the Redmond campus. The best work is done by culling experts of individual niche areas from around the globe. Not surprisingly, this is the model that Linux and most Open Source software uses, and that is why OSS is phenominally successful compared with any of its proprietary competition.
Most of Microsoft's problems can probably be directly attributed to the size of its development team. MS project designers might do well to re-read The Mythical Man-Month (if they never read it, they have no business being project designers, IMO).
Finding God in a Dog
# Code review. Code review is a power trip and best, and a drain on morale at worst. If a programmer cannot be trusted to develop excellent code, he should be replaced with somebody who can. It's a tight labor market on the developers' side, so incompetent programmers should be spending their time reading O'Reilley books instead of playing games and looking at porn in their parents' basement.
No, no, no. Code-review is VERY USEFUL. No, it won't catch architecture mistakes (necessarily). No, it won't catch design mistakes. Hopefully you already know how to design before you get your first software job.
What code-review catches is the annoying things that the best developers tend to think don't matter so much. Style-differences from company practices. Naming conventions not being followed. Poorly chosen variable-names. Lack of documentation.
In short, code-review makes your code more maintainable. Your company may not use it, but that doesn't make it useless.
It seems that Microsoft does not use Visual Source Safe for Windows source code.
Microsoft claims IE can't be separated from the OS. Yet, the presentation points out the code is broken into 16 sub-projects, largely isolated from each other, and separately buildable.
Two of those projects were "INetCore" and "INetServices".
So why can't you just build 2K without those 2 subprojects, or just stubs inserted for the functions declaired in those projects?
sometimes it makes sense to read the article before you comment. (i know the chance is smaller to get modded up ...). the article says:
Complete build time is 8 hours on 4 way PIII Xeon 550 with 50Gb disk and 512k RAM
keep it simple.
The proper care and feeding of trolls...
Eitehr you're a troll, or you've never done any real development.
UML, can't comment on. Never did any. What I can say is that design is important, and shooting from the him on 20million lines of code won't get you very far. If UML helps you design, use UML.
Formal checkins. In large complex projects, you need to be absolutely sure about your units. So many places for things to interact, if you don't have them as solid as you can get it, you'll get so many interaction bugs you'll never get anything done.
Developer time costs $20-40 an hour. Ha, now I know you've never done real programming. Developer wages start maybe at $30/hr (not $20), up to $100/hr at spots. Thats just wages, not benefits, taxes all that stuff. If you have no experience in big projects, don't talk.
Code review Code review is easily the best way of debugging. Study after study find that Code reviews find more bugs per unit of time than any other technique. as side benefits, it also transmits techniques from developer to developer. This comes from developers who want to learn and 1) too shy to ask 2) don't know that there is a better way. I learned something in code reviews, some techniques I never thought of.
Can it be a power trip? yeah. CAn it lead to a clash of egos? yeah, but thats up to the review lead to control. A good review lead will keep that in check.
Large, geographically concentrated development teams
Not surprisingly, this is the model that Linux and most Open Source software uses
They have no option because they can't pay developers, so no chance to get them in a concentrated area. There are plusses and minusses with the concentration.
why OSS is phenominally successful compared with any of its proprietary competition
Sales? No contest. MS.
On what definition of success? Bugs? I've seen some really shitty OSS software. yes, the kernel is high quality, Apache, FreeBSD, others.
Given the tone of most of the comments here, one might think that the slides merely reveal Microsoft's errors. In fact, they indicate what problems the company faced scaling their NT development team from 200 to 1400 programmers and their solutions. The conclusion is, "With the new environment in place, the team is working a lot like they did in the NT 3.1 days with a small, fast moving, development team."
As Linux grows, it is headed for the same sorts of problems. The open source movement can learn a lot from Microsoft's struggles. The fact that Linus opted to use a new source control system -- just as Microsoft realized that their in-house system was not up to the task and so switched -- gives me hope.
P.S. May we please have better summaries for the articles on the front page?
What's interesting is comparing what Showstopper says to the claims in these slides.
The slides suggest early NT development was done by a small team of super l33t c0d3rz who took care of business and frowned upon slacking. However, the picture painted by the book is dramatically different -- people were forced to work around the clock, the team was dominated by a small gang of guys who were basically complete assholes, everybody walked on eggshells for fear of pissing off Dave Cutler, The New Savior, and NOBODY in the group ever knew what was really going on. The whole project was shrouded in mystery, even to people on the team, because basically everything existed in Cutler's head.
The only thing I see where Showstopper and the slideshow firmly agrees is the slide labeled "Goal Setting".
I personally have a lot of other opinions about why some of the statistics may pan out the way they do (for example, how much hardware did you REALLY have to test with in NT 3.1 days, versus Win2K?) but I want to stay focused on the Showstopper/slideshow discrepancies, so I'll leave it at that.
The thing to realize about Showstopper is that it was based almost entirely on interviews with the people who were involved with the initial NT coding effort.
By comparison this slideshow was written by one guy, Mark Lucovsky, who gets lightly flamed in Showstopper (at best). Oddly, I grabbed Showstopper off my bookshelf and opened it straight to the page describing Lucovsky. Weird. Anyway, here are excerpts from a single paragraph: "...smart but immature... nevertheless angered teammates with his skepticism and self-serving judgements... relentlessly critical of others, constantly probing for weaknesses... 'Until you prove otherwise, you're wrong and he's right.'" Whew, hate to be THAT guy. It gets worse. One page later, a paragraph opens by simply saying, "Many people felt that Lucovsky was a jerk."
Given that, it wouldn't surprise me if Lucovsky was still just trying to justify the fact that the early NT dev team was comprised of a bunch of flakes who had to burn the candle at both ends to actually deliver anything.
Please understand I'm not necessarily defending any current MS practices, or even Win2K (which is still vastly superior to NT3.51). I've personally worked VERY closely with groups inside MS at different times (a couple times on-campus in Redmond), and I'll be the first to tell you the company is bureaucratic and packed to the gills with people who don't know what the hell they're doing -- just like every other company that employs tens of thousands of people.
What I *am* saying is that this slideshow is looking at the past with "rose-colored hindsight" and I believe the motives are suspect at best. Draw your conclusions with a grain of salt. (Enough metaphor-abuse for today.)
Do like johnjones suggested -- go buy or check-out Showstopper and read it. It's interesting, informative, and it IS kind of funny. It's amazing they were able to produce anything at all. How's THAT conclusion for contrast with the slideshow? ;)
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005