Slashdot Mirror
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.'"
Enrapture the customers
Shouldn't that be shrink-wrapture the customers?!
Essentially great software is the one that solves customer's problem. Microsoft is good at it as each product that goes out the door can generally be qualified to solve at least one problem.
The "rest of the world" has no clue about the nature of software. That quote is absolutely correct.
Sometimes it's best to just let stupid people be stupid.
How Microsoft develops software:
(1) They notice a great software idea by another company.
(2) They ignore it.
(3) They realize it's big.
(4) They copy it.
(5) They "bundle" this software in the next version of Windows.
(6) They eliminate the competition using their desktop monopoly.
Number (5) can be substituted by "They buy the company".
Microsoft doesn't develop software, they copy or buy.
I find point 12, "Portability is for canoes" either self-serving to Microsoft interests or an interesting insight into their thinking process.
I fight this idea all the time in terms of supporting more than just IE on a web site's design ("it has 95% market share, etc"). I've seen it in the past on supporting Macintosh platforms, and now I observe it in the industry as a whole in driver support, applications, games, etc., when it comes to Linux.
Maybe I'm taking it too far. Portability can be hard to manage and achieve, but somehow I think if this was coming from the purveyor of a non-dominant OS platform player it would sound a little different.
Overall, I liked the article. Nice to see some more analysis of success factors in project management.
No, it does not, but thank you for displaying your ignorance of software engineering principles. A defect is not just a bug; rather, it's a bug that has been found, documented, and fixed using a software engineering process. Not all defects are fixed every time a piece of software goes out the door--think of triage. Is the fact that the buttons render 15 pixels apart instead of 14 going to break the software when it goes out to market?
The "bugs" referred to in the article are software issues that haven't been found, which is why the article warns developers not to assume that "zero defects means zero bugs."
!#@%*)anks for hanging up the phone, dear.
Um, crap. 'Zero Defects' means 'Zero Defects'. If you mean, 'An acceptably small number of defects', then just say so. I still say it's Microsoft double-speak.
www.lucernesys.comHorizon: Calendar-based personal finance
I never thought "too much money on hand" is a problem, at least to me. It usually is the other way around.
6. Beware of a guy in a room.
Linux was written BY the guy in the room.
That's the whole difference in a nutshell.
Check out my sysadmin blog!
Too bad you have to go AC just to say something good about Microsoft!
You certainly bring up a good point, though - there's a fine balance before working on a product until it's completely flawless (by which time it will be obsolete), or rushing a product that solves today's problems to market before it's completely bug-free. Corporations, naturally, have strong motivation to getting the product out quickly, so as to take advantage of market opportunities.
Stop by my site where I write about ERP systems & more
Yes, but that "problem" is generally just the previous release :D
1. Don't know what you don't know.
Yes, and I would also add that feigning ignorance is much safer than feigning self-confidence, and it helps projects to thouroughly research information that is even considered known.
2. Get to a known state and stay there.
I disagree. I think we should accept that we are only ever in a state of the unknown, so that we may prepare for the worse. Don't stay in a state of the known, because then you are ripe for the unknown to come up and bite you on the ass.
3. Remember the triangle.
Resources, features and the schedule are indeed important, but I would also add that there are core features that must be adhered to in order to prevent disasters, which are not features, but critical systems. Sometimes companies like Microsoft will push for more and more features, when a much simpler system will work better and have stronger core competencies.
4. Don't go dark.
I would have to agree with this, but it could also be identified as avoiding feature creep by keeping it simple-stupid. Microsoft adds too many features that require a plethora of miniscule details in order to work, and that often throw off stability of the rest of the system in doing so. Going dark in some areas is going to happen, so I would put that you should go dark wisely, by accepting that at times in the project the team will be in a state of the unknown. Ensure that core competencies are structured correctly to accomodate individual feature additions without delays or growing instabilities. What it comes down to is smart planning and a lot of foresight, but even less features, but enough to get the job done.
5. Use zero defect (ZD) milestones.
I disagree. I think every milestone has to be understood completely for what it is, but it's got to be bug free or it's a fail, in my books. And you should understand the milestone failures along the way because that's part of team building. If you code up a module as one of your milestones and it has a few bugs, you have to track down why they are there and set that as a new milestone -- not skip to the next official milestone.
6. Beware of a guy in a room.
Read Donald Trump's book, How to Get Rich (2004). There is a part in there when Trump talks about a guy who is constantly late all the time, who isn't speaking with employees, and isn't working as a team member properly. Some employees start complaining, and Trump informs them to ask the guy if he needs his laundry picked up or a coffee or lunch brought to him. Trump reminds them that the guy started acting this way just a few months before a multi-million dollar idea was worked out, alone in his office. He says that whenever the guy acts like this, he's about to shake the company. You have to accomodate programmers like this too, and to do so, you can't be looking over their shoulder all the time. I think you should not beware of a guy in a room, but you should change your schedule to accomodate them, and ask for updates from time to time. You have to trust your people or it won't work.
7. Never trade a bad date for an equally bad date
I would agree with this, but if possible you should follow the Id Software motto, when it's done, instead, because only then will you reach the zenith of design and programming practice. Just don't take it too far like some of the other companies with games due out in the late/mid nineties that we're still waiting/not-waiting for.
8. When slipping, don't fall.
Duh.
9. Low tech is good.
Only if you're at Microsoft, because that's all you've got. *zing!* Seriously... the guy says, "A smaller effort is almost always more desirable than a larger one." Can I just say that it reminds me of the commercial with the underachievers? It hinges on putting forth a paced effort, not a minimal output. Sometimes you have to do some work.
10. Design time at design time.
The dangers of knowledge trigger emotional distress in human beings.
Isn't that the point though. Scott Adams has observed that people inside most companies act in very disfunctional ways because most people *are* disfunctional.
The real problem is that we expect people to be more rational and logical just because they are at work and that is not a valid assumption.
SYS 49152
I don't think anyone would stoop so low as to say they put out the WORST product out in the market.
well, ill say one thing. microsoft's windows me was definately one of the best operating systems around when it came to drawing white text on top of blue backgrounds.
Gyrate Dot Org - "Where high-tech meets low-life"
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
I don't think anyone would stoop so low as to say they put out the WORST product out in the market.
I don't want to get into a flame fest, but since you claim they don't produce the WORST product in the market, and since Windows is such a large part of their revenue, I challenge you to find:
Please limit your responses to commercial vendors. Naturally, we'll exclude non-profit and free-software vendors because they couldn't possibly have the financial resources necessary to produce quality software.
Why is it that everyone looks to Microsoft for advice on code quality when, after 20 years of writing operating systems, they still can't keep it from crashing? Microsoft's genius lies not in their code quality, but in their marketing department . A study about how Microsoft markets their software would be much more enlightening; their code quality is nothing to which we should aspire.
The society for a thought-free internet welcomes you.
Bullshit. I develop software, and have done so since '72. "Zero defects" is an absolute statement. One can wiggle all one wants, redefine the meaning of "zero", or redefine the meaning of "defects".
Still bullshit. A bug is a defect.
These "21 Rules Of Thumb" are distilled from McCarthy's "Dynamics of Software Development" book, which has been on the bookshelf of almost every dev lead I've ever worked with or known. You could have a similar "argument" about how good IBM software is (WebSphere?), but at the end of the day, if you're doing it to critique The Mythical Man Month, you're going to sound really dumb.
More importantly, all bitching about MSFT quality aside, McCarthy was dev/program manager on Visual C++, which is not a poorly-regarded Microsoft product (it's one of the best compiler products on the market). There are extremely successful products --- successful on every axis --- that come out of Microsoft. Visual C++, and McCarthy's book, represents one of them. Microsoft Excel, and Joel on Software, represents another.
Microsoft is a huge company with an enormous talent pool and many very qualified, very effective well-jelled teams. You do not sound credible when you try to tar them with the "Microsoft is buggy crap" brush, especially when you're arguing with McCarthy or Spolsky.
"Wow, your use of the language is almost as much fun as Microsoft's. Bugs, defects, software issues? ... We're talking semantics here, not methodology, because Microsoft is a marketing company, not a software company."
Microsoft isn't 'marketing' here. It's one engineer talking to an audience other engineers. He is using the proper terminology (bugs, defects, issues) to describe what's going on here, just like the QA people do in just about every software company.
You're confused because you don't understand the nuances of the terms used. That's okay, I wouldn't have either before I worked in QA. That doesn't mean that MS is intentionally trying to confuse you. It only means that you need to be a little more open minded. I'm not saying this to be a jerk, but rather because you're attacking everybody's rebuttal instead of understanding that there really is a difference between the terms.
Here is how I understand the terms. I may have them a little off, so correction is appreciated. My work in that department was informal at best.
Bug == The code was just plain written wrong. 2+2=5. Sometimes this term was used to describe unexplained behaviour.
Software issue == The software does exactly how it is designed, but it creates an unexpected problem. "Automatic update auto-installs Windows updates every single evening. This is great! Unfortunately, some of them require a reboot, and the user either has to live with the imminent reboot or not getting the updates eveyr night."
Defect == Problem that has been reported. "Defect #32516: There is a typo in the about box, Windows was spelled with an L."
Yep, 3 distinct terms.
"Derp de derp."
I don't want to get into a flame fest
Right.
, but since you claim they don't produce the WORST product in the market, and since Windows is such a large part of their revenue, I challenge you to find:
First of all, the question itself is ridiculous. I can quite genuinely say that Windows XP has never crashed for me or been broken into. However, Linux has frozen up on me several times, and it has had kernel exploits in the past. But that doesn't make Linux less secure or less stable.
The fact that Windows is used WAY more than Linux means you'll get a greater total sum of crashes and breaches, but that doesn't make Windows less secure or less stable. You're arguing a ridiculous premise.
* An OS that is less secure than Windows.
Remember that Slashdot article about how Linux was the most-breached OS on the net? I sure do. A Slashdot editor even modified the headline so it said "Linux Most Attacked OS On Net" instead of "Most Breached" so it didn't look as bad.
* An OS that crashes more frequently than Windows.
Windows never crashes for me. I haven't seen a BSOD since 1999. But, Slashdotters seem stuck in the late 80s and think Windows 98 still represents the stability of Windows today.
I had Gnome crash my laptop under Red Hat 9 the very first time I used it. So fucking what?
* An OS with a EULA more restrictive than Windows.
This is a silly question to throw in. Windows' EULA isn't much more restrictive than, say, IBM's EULAs or Apple's. As if the EULA has anything to do with the operating system itself. Complain about the legal department but not the software development department.
* Software which has slipped the scheduled release date more often and by a larger margin than Windows. IIRC, Microsoft hasn't released on OS on time in the last 10 years.
Yeah, and how late was 2.6 again? Oh, that's right, it shipped a year later than Torvalds said it would. Again, this is a completely ridiculous argument.
I know it's l33t to be a raving Linux zealot, but a lot of people are really getting tired of it, as evidenced by the posts I've been seeing lately that are getting upmodded. I'm very pleased to see more and more people approaching things rationally and fairly now--even if Slashdot editors don't. The very fact that Clippy jokes and BSOD jokes are still upmodded--two things 95% of Windows users haven't seen since 1999--shows you how stuck in the past zealots are and how they won't let go of their old Windows 98 experience. They're competing with old 9x versions of Windows when meanwhile everyone else moved on when the codebase unification to the NT kernel happened in late 1999, and we got Windows 2000.
But, I forgot. This is the "year of Linux on the desktop." Hey, remember that article Slashdot posted that said Linux desktop usage would overtake Apple's in a year? I even had one Slashdotter cite it to me as evidence for a point he was making, simply because Slashdot had reported it. So much for that.
If you're a Linux newbie and you're coming here for tech news, you're doing yourself a great injustice, as everything will be skewed and you will get a huge wrong impression about how the tech world is doing.
These rules of egoless programming have been circulating on various sites:
Like most platitudes, they apply in some situations and not in others and there are plenty of valid exceptions.
For instance: Treat people who know less than you with respect, deference, and patience -- but don't let them tell you how to do your job.
Or: Fight for what you believe, but gracefully accept defeat -- and when you turn out to have been right, don't let anyone forget it.
Does every piece of software have bugs?
Does Knuth's TeX program have bugs? He will
send you a cheque if you find one
TeX was designed, then implemented. It works
You certainly bring up a good point, though - there's a fine balance before working on a product until it's completely flawless (by which time it will be obsolete), or rushing a product that solves today's problems to market before it's completely bug-free.
I've found that the "release early, release often" philosophy works very nicely, if you make it painless to update.
When I wrote my most recent, decent-sized project, I wrote it in mind with built-in updates so that with almost no effort whatsoever, I can issue updates and patches and the program will notice, when online, that these new patches exist and offer to download them!
Time to issue a new release of the software (for me) now is about 15 minutes, including time to upload the files to the server, and configure the server to publish the updates to the client software packages.
I pay *alot* of attention to backwards compatability - a new update will not break data files or expected functionality from older versions, and there's a fairly elaborate document format version management and error detection system in place to ensure that the rules aren't broken.
It's not atypical for me to discuss a bug with a user at 12:00 in the afternoon, and have the bug fixed, patch file published, and the user using it by 3:00 PM.
Along with the patch distribution, we also back up the user's data files (in an encrypted form) so that if their computer crashes, gets stolen, whatever, we have backups of all their valuable data. They press a button and have all the data downloaded back onto their computer in minutes.
The users LOVE IT!
We're no Microsoft, but we have around 500 end-users using our niche-market software.
I have no problem with your religion until you decide it's reason to deprive others of the truth.