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.
Surely a quick goat killing is required at least before check-in
So for something like Windows 2000 is that a long time?
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
Of course, knowing MS, they would do it in the middle of the day.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
not really I suspect that they have a few tricks up their sleaves
what would really be fun would be to know what version of the compiler they are useing
win2k it was Visual C 6 I wonder if they changed for XP
regards
john jones
Geez, I run at 1600 by 1200 and I still had to scroll every 10 lines or so. I got people yelling at me down on the street because I read slow.
This reminds me of an old article with the name of this subject that came out around the mid-90's about Microsoft's sync-and-stabilize methodology. Really not a lot new here, save the amount of time they required to build their OS.
Rule #1 -- Politics always trumps technology.
Only the NT build lab needs to rebuild everything. Individual developers only need to built their feature's DLL and EXE files.
cpeterso
show stopper from
when has been recomending books on the subject a troll (and it was done by someone with unlimted
Imagine how hard it must be to co-ordinate a project that big without "management". I think Linux could gain by creating a kind of unofficial management structure to better co-ordinate some of the projects.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
I'm a linux user, but most MS people I know hail win2k as the best microsoft OS ever. So this presentation seems to be kind of strange, pointing out things (increased build time, developers/testers) that illogically seem to create a better OS.
it may have taken 8 hours, because they had to reboot twice.
I write code.
I sorta doubt that 8hrs was spent only compiling the win2k "kernel." Don't forget that the GUI, networking and a ton of other crap is built in. I'm sure compiling an entire linux system consisting of apps equivalent to those which are built into windows would take a hell of a lot of time too.
cpeterso
"Showstopper!" was fascinating. David Cutler really is a genius. NT had the potential to be a truly great operating system. I would have loved to have gotten a chance to play with it before they bolted win32 on top of it. Everyone who has the slightest interest in operating systems should read Showstopper.
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
Try linuxfromscratch.org. Okay, it's to get a personalised build, not a CD installation, but my Celeron433/196MB was running solid for well over 24h to build a whole system. Probably more like 36h, certainly took about 3 days (though obviously I couldn't always co-ordinate it to be busy all the time I was asleep, only X, etc, take that long!)
Author, Shell Scripting : Expert Re
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
Good engineering (of any kind) starts with design... a plan. I'm glad you don't build skyscrapers or airplanes. Oh boy. So you basically are thinking... what... that code should be reviewed after it has already hit QA or something? Or perhaps we shouldn't review code at all?
Here's a clue. If a developer is costing 20-40 per hour writing CRAPPY code... THAT is a far worse waste of time than taking a little time... reviewing the code... and correcting it if necessary.
Development isn't just writing code any way you want. You want things to be very solid, standardized, and consistent before it gets into beta. Using your way... you'd never know if the code was good or not. Apparently... to you... if it works... ship it! What? How do we know if the code is bad? We have to REVIEW it? What if the developer doesn't understand a certain design pattern and implemented it incorrectly? Hell... what if a bug or flaw is discovered during the review process?
These are all common issues in everyday development. It doesn't necessarily mean the developer is BAD. Rather... the developer is HUMAN.
Although... with your lack of a code review process, lack of system design process, and lack of formal check-in process... I am surprised that any decent code gets written at all. You're comparing apples and tractors. Financial gain or customer/user base size are NOT measures of good code, excellent development standards, or strong design processes. Although, I'm not certain you will understand what I'm saying here.
There is some excellent open-source software out there. Likewise, there is some excellent proprietary software out there.
And there is crappy software out there, too... for both worlds. Whether or not something is open source or proprietary says nothing about how it is written or how well it is designed.
This obviously is a huge troll that I'm feeding here.
I think you're way off-base on the Code Review comment. At my job, code reviews take roughly 3-5% of the time I spend writing code, and very often find problems (in having my own code reviewed, or reviewing someone elses code).
And even if no bugs are found, it helps to have another pair of eyes go over code for readability. It may make sense to you, but it may not to someone else. When you leave and that code needs fixing, NOBODY will understand it because they don't have preconceived notions about how it operates.
The BEST thing you can do to improve quality of code, and of your developers, is to code review before every checkin. Find someone who is more/as intelligent as you, and have them scour your code while sitting next to you. At worst, they'll understand the code. At best, you'll find a bug before it goes out there, or you'll learn something new about the language/library you're using that you didn't know before.
MAD MAD props on the Ghostbusters quote.
El riesgo vive siempre!
Hats off to the staroffice teams for a nice job well done.
- This sig deliberately left blank. Nothing to see, move along.
# 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.
if they are using SourceSafe.
word.
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?
Even if that's 12 hours a week, Hans is just NOT a programmer. ;)
sic transit gloria mundi
Others (like Use cases IMHO) suck and are of little use to programmers, though more in communication with PHBs and business types.
I've found use cases to be really useful. Two reasons:
But at the end of the day, bad programmers make worthless (but compliant!) UML diagrams/use cases/flowcharts as do programmer who are forced to create them. Good programmers make good ones or don't need them.
Formal checkins. Make you own branch and go butt nutty in it. Sync to the trunk often. Let them review your changes and integrate on their own pace. Code review. Once again - having anybody - even inferior programmer to look over your code will do wonders to your own understanding and skills. I am a good coder, and I beg other people to review and comment. The more I ask - the less problems they find - I am getting better. I hope you do not assume that you have no way to improve - otherwise: you are a big fat liar. My goal is to write code so clear that they can understand what and how it does without my help. Large, geographically concentrated development teams. That one I would agree. Adding people slows everything down. Full team should not be above 20 engineers, and some QA - above that, keep splitting projects. If you think it is not possible - you are a lousy architect.
<^>_<(ô ô)>_<^>
> Spoken like a true idiot, my friend.
Surely a troll, IMO.
> The UML is NOT a fad.
Yeah, I'm usually pretty cynical about this kind of stuff, but I've found UML useful for documenting the basic structure of very complex programs.
Sheesh, evil *and* a jerk. -- Jade
Thank you, this needed to be said. Developers do not recompile every object file when they build a new binary, only what has changed. The master build is only important so that every one is linking against about the same code, and there is one standard that is referred to as the teams output.
-- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
I always figured that their development methodology invloved a room full of an infinite number of monkeys typing into Notepad. Learn something new everyday.
They have to be Xeons, AFAIK, non-Xeon Intel CPUs won't do 4-way. And even if you CAN do 4 way on regular PIII's, which you cannot, MS wouldn't, they would have Xeons.
I'm imagining this machine to be a Compaq 6400r or the like, from the timeframe of the build it's probably 550s or 700(?), since they have a very close relationship to Compaq for servers.
I like music
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.
UML and other modelling fads.
While UML isn't the end-all, be-all, it is certainly not a "fad". When it comes right down to it, your will need to be able to describe the architecture of your code with something more than comment-lines and manpages. And, with the "U" in UML standing for "Unified", the is the ability for a new-hire developer, or perhaps the purchaser of your source-code, to understand what the hell is going on without pouring over millions of lines of source code.
Code review is a power trip and best
I suppose you'd rather accept source code sight-unseen? True, there are good and bad ways to conduct code reviews, but all the code reviews I've been a part of have been a fairly easygoing experiences and almost always helpful. Sometimes you really need another set of eyeballs to catch problems. Isn't that one of the good aspects of OSS??
Large, geographically concentrated development teams
I'm torn on this one. Yes, it's bad to simply throw a large number of developers on a team (unless you break them down... way down). On the other hand, you can't tell me that it's not easier to resolve a problem by walking over to the co-worker in the next cube than than email the co-worker who lives thousands of miles away. Didn't the formal release of Mozilla 1.0 get held up because a few key developers had not signed off on the new open source license and they simply could not be found??
the later slides describe the NEW project resource management and development processes for the continuing development of Windows 2000 (before and up until after the release?)
Slides 23 and up tell you what they did and how well everything works on a project as large as Windows 2000 is.
This slide gives a sumary of the new build processes http://www.usenix.org/events/usenix-win2000/invite dtalks/lucovsky_html/sld033.htm
I follow the SDK and GDN principles.. Spelling Dont Kount, Grammer Dont Neither
But here is part of the whole point...
The Linux system I'm running when not booted to the Dark Side (My daughter was running Age of Empires - more Dark Side software.) isn't a single chunk that has to be built as one unit. The kernel's one piece, and each lib is another. To be sure, some libs won't work without specific versions of others, so the pieces aren't all independent. But it's still not all one giant chunk.
They're essentially making the RedHat distribution into one giant build. Kind of like Gentoo, which someone else brought up, and is a very appropriate comparison for build times.
But even with RedHat or Gentoo, it's not one giant chunk. I've upgraded pieces of my RedHat for years, and to be fair, Microsoft issues fixes. But there's still a difference, in that I have a better understanding of what RedHat's doing with an update, and better understand what parts of my system are affected.
While there may be modularity inside Windows, it appears to be intentionally hidden from the end user. I wonder if that's part and parcel of proprietary software, or if it's a side effect of the legal team arguing that Windows is "integrated" and IE can't be unbundled.
The living have better things to do than to continue hating the dead.
From the presentation:
"Anything that crashes the OS is a bug. Very radical thinking inside of Microsoft considering Win16 was cooperative multi-tasking in a single address space,..."
So the BSODs were caused by the old-timers? Were they also the ones who designed in the feature that every fucking install of an application requires a reboot?
Remain calm! All is well!
One, I've always found code review beneficial for a project. Weaker coders learn good habits; stonger coders teach good habits
There is code reveiew and there is code review. I tend to take a very sour view of formal code review meetings, except under special circumstances: Better understanding problem code, guiding new programmers (and, even then, I'm not sure) and carefully reviewing things that a) have to work very well and b) must be very well understood by those whose code will interact with them.
Formal code reviews, unless managed very well by a competent and confident moderator, can easily degenerate into "See what I know!" fests whereby lots of folks who haven't lived and died with a problem pile on the person who has.
Formal code reviews often have an unintended consequence: they can (not must, but can) reduce the level of informal review, coordination and help that takes place. You know what I'm talking about : "Leave me alone, kid. I've got my own schedule to meet. Besides, that's what the code review is for."
Informal code reviews -- "Hey Jack, take a look at this, would you?" should be happening all of the time. Some managers (and developers) may believe that time spent huddled over a terminal together is half as productive as time spent alone in front of a terminal, but nothing could be further from the truth.
BIL 9000: I'm sorry (Judge) Jackson, I can't let you do that.
We have an automated script to take your changed files and copy 'em over to a share. Then we send out an e-mail to the team (small) and say it's going to be committed soon. One person is assigned "primary", and must look at it; everyone else can optionally.
It doesn't take much time, but it's only the smallest CRs that get away without at least a few changes. Sometimes it's just comments, sometimes it's a better way to do something. At the least, everyone has a better idea what's going on in code they're not in right now, but very well might be in the near future. An added benefit is that people who see CR coming clean up their code a bit more than usual.
I agree-- formal CRs suck in most cases (although some critical apps developers like them for some bits of code that might, say, kill someone if they malfunction, or that take $10,000 to test). But the e-mail deal works really well for our team. But we don't have any assholes or know-it-alls, so that helps.
If you go through the whole presentation, you will see that when the Windows 2000 team was working as a single centrally-co-ordinated group, it was slowing them down and causing stagnation.
It was only when they broke up into smaller, relatively independent groups, that they managed to regain some of the earlier productivity from their NT days.
And that's how Linux development works -- many small, relatively independent development groups.
With Windows, Microsoft even ties the applications into the Operating System, with the purpose of making the use of non-MS applications "a jolting experience" (as an internal Microsoft memo said about IE versus Netscape).
But with Linux, everything is developed to standardized interfaces. That makes it possible for the Kernel development to progress independently of the GUI development, which is independent of the development of the Desktop Managers, which is independent of the development of the Applications, which is independent of Distribution Packaging, and so on.
Even within the larger projects, such as the Kernel, or Mozilla, the work is divided into smaller, relatively independent modules.
And that's one of the reasons why Linux development is progressing so much faster than Windows.
The problem with code review is that programmers have egos. Big ones. They just get arrogent and defensive, even if they're good programmers. I've worked with enough to figure this out, particularly about the ones who have been programming for a long time, but have always done shitty jobs.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
Remember that Windows 2000 is essentially everyone who is working on the linux kernal, basic distribution, and X. If the number includes Explorer, which could be likened to Mozzila and includes management, testers, and all the design specialistics ( people who do research to make it user friendly, or handicap accesable, I would think it's pretty small.
Besides, how do the compilers compare in speed? (there'd be an almost totally useless benchmark)
All in all, I would say that a comparable gnu/linux system (kernel, base stuff, X, KDE or Gnome, plus a few other bits and bobs) would take a bit less time than this, but that's just a guess at best. Perhaps some of the Gentoo and LFS users can shed some light?
sic transit gloria mundi
UNIX and Linux are different. UNIX (at least Research UNIX) was constrained by its paradigms: it was vigorously policed by its developers. For Linux, something doesn't make it into the kernel unless it really scratches an itch that a lot of people have--the feedback is immediate and direct: no interest, no developers.
Microsoft software development doesn't operate in a competitive market of ideas (let alone a competitive market), it doesn't have a paradigm to focus it, and it doesn't even have resource constraints to focus it. It's nice that they make the software engineering work out, but the end result still is mediocre at best.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
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.
Full text of Proudly Serving my Corporate Masters here...
Just in case you wanted some more insight into working for the company. Fascinating stuff.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
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.
Not to mention that any such company has a responsibility, driven by enlightened self-interest, to turn Jr. programmers into expert programmers.
ideally, the build will only break if two changes on the same night contradict each other
Another reason a change might break the build is if the software builds on multiple platforms. I think this is one reason Mozilla has dozens of computers continuously building it rather than one nightly build that may or may not compile the first time. This doesn't catch all checkins that make Mozilla unusable (we have a "smoketest" team that make sure each nightly works well enough to test it), but it does give everyone immediate feedback if a checkin stops the build from compiling or makes it fail some automatic tests.
Of course, it helps that compiling Mozilla takes less than an hour.
The shareholder is always right.
Whuh... Did I just hear a slashdot geek call Microsoft employees even bigger geeks? I'd take what your friend told you with a grain of salt, especially since it doesn't make much sense. I actually worked at Microsoft for a few months as a university student, and my impression was that the workers there were pretty normal, as far as coders go. I've met a lot wierder people since then.
I was working on a pretty trivial part of NT, so the build system didn't affect me. However, when you walked around the halls you could see who checked in code that broke the build because they would have a "build breaker award" taped to their office window. It seemed to be in good fun, but I suppose it could result in a CYA mentality.
Also, I remember there being problems with source control, like the article mentioned, though not specific to NT. I seem to remember that Word Viewer used a different codestream from Word and the sample files in the SDK are merely very out-of-date versions of some of the small apps that ship with Windows.
-a
How to rationalize theft.
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?
they already do charge a "bunch" of money for access to the source code.
sic transit gloria mundi
The original team's goals, as you listed them, look great, especially for a server OS, and the positive results showed in NT 3.51.
Unfortunately, Mr. Gates was not as technically competent as the original NT team, and he provided a new set of goals for NT 4.0:
1. Snazzy GUI - For a server OS!
2. Good GUI performance - Run video drivers in kernel mode (ring zero).
3. Cool new features - Good games platform.
4. Other considerations, such as reliability and compatibility, are secondary.
The fact that Bill Gates overrode the goals of the original team made it impossible for NT 4.0 to compete with Unix in the high-end server market.
Now, even if Microsoft happened to get it right with Windows 2000, no one will believe them.
Unfortunately, if you look at Netcraft's measurements, you will find that the major W2K sites has uptimes averaging less than 10 days, while the major Linux sites tend to have uptimes of around 100 days. That, combined with all the security holes in Microsoft's software, will tell you that they still don't have it right.
Slide 19? Anyone? I can't see it in IE 5.01 sp2 or Opera 6.02...
What is serialized development?
Anyone use SourceDepot? Opinions?
WTF is that big X in Slide 31? Zero parallel development?
[o]_O
All for wimps. I always start from stage -3. This means no machine-readable media whatsoever and a blank system EPROM. Nothing but source code printouts.
After 36 hours of entering bootstrap code via a bank of toggle switches, you can get to stage -2 (TTY keyboard and video on a temporary BIOS). After this, you've still got a long road to hoe before you get to a login prompt. It's well worth it though, if you want to know exactly what your system is running.
Two words:
Library Stripping.
I've seen Windows 2000 request a reboot when moving an installed USB modem from one USB port to another. So it's not as though unnecessary reboots are something from Microsoft's dark, distant past.
Not everyone can know everything. Why discriminate against good information based on its age?
Can you see the spelling error you made in this sentence? Did you mean to make that error?
If you can't even type error-free prose, how could you be expected to create error-free code?
People make errors. Code review helps reduce the effect of those errors.
"You can justify anything by putting it in quotes, adding a famous name and making it a sig" - Albert Einstein
Some goofy Microsoft Intern forgot to put -j 4 along with compliation.
Either that, or they compiled it on Win9x (which has NO multiprocessor support).
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Then they used 2k to compile xp (crashed once)
OR:
Time to compile 2k: 8hrs
Time to drag 'Luna' into 'Skins' folder: 2 min
Time to play minesweeper: 1hr 28 min.
Free Java games for your phone: Tontie, Sokoban
It looks like Microsoft adapted well to the problem of source control and building.
Well, that's an oxymoron for you!
Make even shorter URLs - 8LN.org
Take a look at slide 19 - 1400 devs, but 1700 testers. Do you suppose that means that Win2k had 3100 people working full-time on it? Lowballing the numbers (55k per dev, 45k per tester):
1,400 * 55,000 = 77,000,000
1,700 * 45,000 = 76,500,000
153,500,000 a year * 3 years (from slide 3) = 460,000,000
Include an overhead multiplier
460,000,000 * 2.4 = 1,105,200,000
And we wind up with a rough US$1.1BB.
This suggests that win2k represents 20 million SLOC, Just slightly higher than RH 6.2, at 17 and change.
His cost estimates place RH 6.2 at US$614,421,924.71
I suspect MS probably pays more per dev, but I have no proof, so I'll stick with the industry averages. Also, testers may have been shared across projects, MS can pool resources and bring overhead lower, etc...
I'm not drawing any conclusions, just compiling data...
Can't find that book on software quality where I read this, would love to give a reference to research on this subject.
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
So what do you mean by "VC"? With those pretty IDE? "cl.exe" is the compiler/linker, and its linker version is 7 in VC7. nt.dll of WinXP has linker version 7.00, and it's enough.
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.
Big deal I worked on a project that had, at that time, 34 hours or so, that was on a 2 way I think though and 4 years. But the project is still growing, more then tripled, since I transfered, according to my friend that still works on it.
Capitalism: unequal distribution of wealth
Socialism: equal distribution of poverty
The The NT Culture was supposed to be based on "Portability, Reliability, Security, and Extensibility" ingrained as the teams top priority.
Portability? Apart from the x86 platform, does it run on any other platform?
Reliability? I still got the occasional blue screen of death in NT 4. (svcpk5) as of last year.
Security? We had regular virus sweeps and updates were NEEDED every time script kiddies got a new mod and would hammer at our systems.
Given the fact that the company serfs were still using NT4 and that they weren't allowed to put in multimedia extensions, Flash and other "Sturm und Drang" sillyness while the Solaris boxes ran Oracle for the databases, I'd say that the extensibility wasn't an issue either.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
OSS is phenominally successful compared with any of its proprietary competition
Tell me again which OS runs on 90% of desktop PCs around the World.
As my company has avoided these measures, it has produced a superior product for a very low development cost.
Is it even 1/100th of the size and complexity of Win2K or any Linux distro?
Code review is a power trip and best, and a drain on morale at worst
You weren't doing it properly. If the coder is less than perfect, it will help to improve both the coder and the code. If the coder is perfect, it'll help improve the coding of the reviewers (who naturally are programmers themselves, not management types).
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I agree! What's next? Reporting something borrowed as something blue? When will it end?
Liberty uber alles.
I have only one thing to say...
(places tongue inside lower lip and rolls eyes) nuuuuh!
-- What do you need?
-- Gnus. Lots of Gnus.
I hear that often, but its just not true:
Management Guy: "When is your part going to be done?"
Programmer Guy: "I don't know, i'm playing Warcraft 3 this week. Whenever I get free time."
Manager Guy: "Well everyone, we're going to have to move the schedule up a few days because of the Programmer Guy. Lets all try to remember we're on a team here." (clicks a few spots in MS Project)
Programmer Guy: "Kiss my ass! Do it yourself."
Volunteers == no firings/compensation == no enforceable deadlines == no reliable planning == no management possible.
Maybe some folks are using it there, but in product development it was not considered an acceptable option for source code control.
The rest smacks of xenophobia. I don't buy into the common myth that style and naming conventions are critical to maintainability.
Seriously, some people use crappy style and variable names. At my last job, someone had written this complicated function using variables like: s1, s2, s3, d1, etc. It made it very difficult to figure out his code, and eventually, I had to change all the names just so I'd be able to read the code a month later.
It's much easier to fix bugs in someone else's code if you can read it. If you can't, you're screwed. You can call it xenophobia if you'd like, but honestly, I'm expressing my experience.
Anyone who can read a complicated C declaration isn't going to have any problem with non-politically-correct variable names or different styles.
Good straw-man. My problem isn't with non-politically-correct variable names (functionToFixBugInLinux() ). My problem is with unintentionally obfuscated code.
Style is arbitrary but functionality is not. If the code review process doesn't consider program correctness, it's a waste of time.
About program correctness: most of the time it's not worth the time required. And no, I'm not talking about security or crypto or compression or anything like that. Those sections of your code should be provably correct. But proving the correctness of your little GUI app is just silly.
On the other hand, style may be arbitrary to you, but for me, style is very important. The parts that bother me are when someone has written a bunch of button code with names like "b1, b2, b3". Or logic like a=((a=read(n)-4)?(b+5):(b+3)). Even if it works now, it will never be maintainable later.