Forgot your password?
typodupeerror
Microsoft Programming IT Technology

How Microsoft Develops Its Software 816

Posted by michael
from the remember-the-triangle dept.
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.'"
This discussion has been archived. No new comments can be posted.

How Microsoft Develops Its Software

Comments Filter:
  • My post (Score:4, Interesting)

    by andy55 (743992) * on Friday June 25, 2004 @10:51AM (#9527912) Homepage
    I posted the following on this guy's blog comment form, and I thought some folks here might agree with it... Yay/nay?

    A worthwhile and insightful read (and it's about to get slashdotted). You use the phrase "great software" frequently. I post this sincerely and do not mean to troll. Since you are a MS PM and/or dev, there seems to be three possibilities:

    (1) MS consistently makes "great software" and you are, therefore, content to be a MS employee.

    (2) MS does not make consistently "great software" and you are, therefore, either unhappy at MS or long to be project group that makes "great software".

    (3) You and other people (myself included) have dissimilar meanings of "great software".

    In short, I believe possibility (3) is the case.
    • Re:My post (Score:5, Interesting)

      by Anonymous Coward on Friday June 25, 2004 @10:55AM (#9527971)
      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.
      • Re:My post (Score:5, Funny)

        by tlhIngan (30335) <.slashdot. .at. .worf.net.> on Friday June 25, 2004 @11:03AM (#9528072)
        I never thought "too much money on hand" is a problem, at least to me. It usually is the other way around.
        • Re:My post (Score:4, Interesting)

          by ezavada (91752) on Friday June 25, 2004 @12:49PM (#9529351)
          I would have to disagree.

          Too much money can lead to throwing more resources at a problem -- usually in the form of buying products or adding more engineers. Bought products rarely just drop right in to what you've been building, so often much time is lost learning the product and adapting it to the rest of your system. More engineers increases communication burdens. Worse still, these engineers are often hired quickly, so they aren't as carefully screened for compatibility with the rest of the team and they aren't easily aculturated to the team's way of doing things.

          On the other hand, when you can't just throw tons of resources at the project, you have to apply serious creativity to solving the problem in a way that doesn't cost too much. Some really great software gets built that way.

          Of course, too small a budget is a problem too. But the defense against that is fairly straightforward. As a PM, make it clear that the project can't be done without at least X resources. The too many resources problem is harder to see happening, because you are spending all your time managing them.
      • Re:My post (Score:5, Insightful)

        by TopShelf (92521) on Friday June 25, 2004 @11:12AM (#9528184) Homepage Journal
        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.
        • Re:My post (Score:4, Interesting)

          by Anonymous Coward on Friday June 25, 2004 @11:15AM (#9528225)
          This one has less to do with development, and more with project management and budgeting.

          Why do most open sources get started? Because we can. Sometimes, as that was the case with GCC, the project was started because it was needed, but most of the time it's just for fun. Essentially GCC is a great software product - because it solved an existing problem. By this definition Visual Basic 4 is also a great product, if your problem was building GUIs quickly. The internal quality of the product varies, however.
        • Re:My post (Score:4, Insightful)

          by bicho (144895) on Friday June 25, 2004 @12:18PM (#9528936)
          Oh, please.
          By that deffinition, there is a lot of "great doftware" out there. And almost not bad software.

          Good Software does what marketing says it does, correclty and as expected.

          Great software is good sofware plus its simple to use and does things that you didn't expect it to do but that come in handy, while not annoying the hell out of its user.... more or less

          just my huble opinion.
        • Re:My post (Score:5, Interesting)

          by mcrbids (148650) on Friday June 25, 2004 @02:56PM (#9531030) Journal
          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.
      • Re:My post (Score:5, Insightful)

        by jkabbe (631234) on Friday June 25, 2004 @11:14AM (#9528211)
        Yes, but that "problem" is generally just the previous release :D
      • Re:My post (Score:5, Insightful)

        by Hognoxious (631665) on Friday June 25, 2004 @11:31AM (#9528399) Homepage Journal
        Microsoft is good at it as each product that goes out the door can generally be qualified to solve at least one problem.
        Solving problems isn't hard. Solving them without creating worse ones is.
      • Re:My post (Score:5, Insightful)

        by MarkGriz (520778) on Friday June 25, 2004 @11:44AM (#9528554)
        Sure, many Microsoft products solve a particular set of customer problems. Yet the same products can and often do create a whole set of new problems (maybe you missed this story) [slashdot.org]

        To me, there is more to "great software" than solving one set of problems. It is solving them well, and well... if you create more problems than you solve, I'm sorry but that isn't "great software".

        Yes, I use alot of Windows software, and no I'm not a Linux zealot (love Knoppix though). With the exception of IE (which I abandoned long ago), most Microsoft software I use (Office, Outlook) is "good enough" but certainly not great.
      • Re:My post (Score:5, Interesting)

        by Decaff (42676) on Friday June 25, 2004 @11:49AM (#9528609)
        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.

        Microsoft is good at providing solutions to problems that the customer does not have, and providing features that the customer rarely if ever needs. Microsoft is really great at marketing, which often consists of convincing managers that they have (imaginary) problems which can only be solved by MS software.

        And, what about problems that Microsoft deliberately creates, which can only be solved by their software? Remember how they sabotaged Windows so that it would not run with a competitor's version of DOS? Exactly what customer problem did that solve?
    • Re:My post (Score:4, Insightful)

      by tb3 (313150) on Friday June 25, 2004 @10:56AM (#9527976) Homepage
      Yep, Microsoft double-speak in action. Here's another great example, "Zero defects does not mean that the product does not have bugs" Well, to the rest of the world it bloody well does!
      • Re:My post (Score:5, Insightful)

        Here's another great example, "Zero defects does not mean that the product does not have bugs" Well, to the rest of the world it bloody well does!

        The "rest of the world" has no clue about the nature of software. That quote is absolutely correct.

        • Re:My post (Score:5, Insightful)

          by tb3 (313150) on Friday June 25, 2004 @11:02AM (#9528064) Homepage
          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.
          • Re:My post (Score:4, Insightful)

            by DerWulf (782458) on Friday June 25, 2004 @11:33AM (#9528423)
            Yeah, out of context this quote doesn't make sense. Just like a lot of 'facts' in moores movies. Reading the sentence before, it actually means 'zero defects for this milestone'. So you got a milestone that says 'additional features available, existing features pass all test cases'. For the logically impaired this means: defects in new features a-ok, defects in prior features no-go.
            I can't help to think that you have no-clue(tm) and are trying to hide it by mixing with the oss/developer crowd since expecting perfectness at every milestone can't come from extensive IT expierience.
        • Re:My post (Score:3, Funny)

          by heinousjay (683506)
          The quote is correct, but only for certain degenerate values of correct. You have to get yourself deep into managerspeak before something like that can be accepted with a good conscience.

          Caveat: I am a developer, and I am aware that the only software that has zero bugs is unwritten software.
        • Re:My post (Score:5, Insightful)

          by Oligonicella (659917) on Friday June 25, 2004 @11:48AM (#9528600)
          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.
      • Re:My post (Score:5, Informative)

        by PhxBlue (562201) on Friday June 25, 2004 @11:01AM (#9528053) Homepage Journal

        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."

      • Re:My post (Score:5, Informative)

        by arrogance (590092) on Friday June 25, 2004 @11:30AM (#9528389)
        How the parent post got +5 I have no idea....

        Actually, much of the rest of the world DOES believe that "Zero defects does not mean that the product does not have bugs". Emphasis in quotations mine.

        Definition of Zero-Defect [wordreference.com]. "an aspect of total quality management that stresses the objective of error-free performance in providing goods or services"

        Six sigma's take on Zero Defect [isixsigma.com] that states: "A practice that aims to reduce defects as a way to directly increase profits. The concept of zero defects lead to the development of Six Sigma in the 1980s."

        Here's an explanation of why people are confused [dotnetjunkies.com] about the subject. Yes, it's an M$ site.

        10 rules for ZDSD [devnewz.com]: "Not to be taken as meaning 'bug-free,' Zero-Defect Software Development (ZDSD) is a practice of developing software that is maintained in the highest quality state throughout the entire development process."

      • Re:My post (Score:3, Insightful)

        by NanoGator (522640)
        "Yep, Microsoft double-speak in action. Here's another great example, "Zero defects does not mean that the product does not have bugs" Well, to the rest of the world it bloody well does!"

        In a QA sense, a defect is a problem that is found as opposed to a defect that exists. For example: If Clippy doesn't give the right response to the word "Hamdingers", but nobody tests for use of the word "Hamdingers", then a bug exists but not a defect. It is not a defect because it hasn't been reported. He meant that
      • Re:My post (Score:3, Insightful)

        by Keeper (56691)
        There is no such thing as "zero defects" in a large software project. There is only a concept of "zero known defects." Every time you make a change to your code, you risk introducing an unknown defect. As you approach the end of the development cycle, getting down to zero known defects is actually detrimental to the quality of the sofware, as unknown defects are introduced which may be far worse than the defects you fixed. And as you're at the end of the development cycle, test doesn't have enough time
    • To be fair we have to give credit for getting the complex projects out. It is very very hard to get a large team to deliver a product and not get derailed.

      But we all know Microsoft software has some severe problems. Security - gets viruses, spyware, trojans easily. Crashes.

      Is this because of the design process or for other reasons? Here are a couple reasons why Microsoft software could have all these problems in spite of a good design process:
      - Keeping backward compatability at all costs. This has b

    • by tqbf (59350) on Friday June 25, 2004 @11:58AM (#9528732) Homepage

      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.

  • by ideonode (163753) on Friday June 25, 2004 @10:52AM (#9527928)
    Enrapture the customers

    Shouldn't that be shrink-wrapture the customers?!
  • Professionalism (Score:5, Interesting)

    by Some guy named Chris (9720) * on Friday June 25, 2004 @10:53AM (#9527946) Journal
    Generally, the whole article can be summed up as this: "Act like professionals". It's
    • Be Honest
    • Communicate
    • Put in an honest days work every day
    • Simple is good
  • Instant Slashback (Score:3, Informative)

    by LittleGuy (267282) on Friday June 25, 2004 @10:53AM (#9527947)
    Compare and Contrast "21 Rules" with The Mythical Man-Month Revisted [slashdot.org].
  • by jamie812 (720355) on Friday June 25, 2004 @10:53AM (#9527948)
    While Microsoft doesn't consistently put out the best products they're capable of, I don't think anyone would stoop so low as to say they put out the WORST product out in the market. As such, it's worth considering how they go about making their software, since it's a difficult job, at best, to get a group of developers to deliver anything. Any tips we can take away as a collective whole would be helpful to us in our larger goals.
    • by Pedersen (46721)

      I don't think anyone would stoop so low as to say they put out the WORST product out in the market


      No, those honors belonged to Rational Corporation (a company whose products were so unstable that it made Windows 95 look good) and IBS, the makers of SBN, the most foul program to ever disgrace the software industry.

      • by GileadGreene (539584) on Friday June 25, 2004 @12:15PM (#9528895) Homepage
        those honors belonged to Rational Corporation (a company whose products were so unstable that it made Windows 95 look good)

        Which I've always thought was exceedingly bad advertising. Either

        1. They don't use the Rational Unified Process (if not, why not?) or
        2. They use the Rational Unified Process (or parts thereof) and still managed to produce a bad product
        If even the people who are touting some magic software process can't use it to generate decent software then what hope is there for all the other software devs out there that have even less familiarlity with the process?

        Process is all well and good, but unless it produces good product, it's pointless. By the same token, once I see the folks at SEI use CMM or their "Personal Software Process" to actually produce a decent piece of software I might actually be convinced that said processes are worthwhile. Until then, it's all just hot air.

    • by gyratedotorg (545872) on Friday June 25, 2004 @11:30AM (#9528383) Homepage

      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.

    • by gillbates (106458) on Friday June 25, 2004 @11:37AM (#9528456) Homepage Journal

      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:

      • An OS that is less secure than Windows.
      • An OS that crashes more frequently than Windows.
      • An OS with a EULA more restrictive than Windows.
      • 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.

      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.

      • by bonch (38532) on Friday June 25, 2004 @12:20PM (#9528981)
        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.
        • by SpyPlane (733043) on Friday June 25, 2004 @12:50PM (#9529368)
          I usually wouldn't reply this late in the thread, here goes:

          My Windows XP box crashes everyday.. literally. My "win"modem for some reason doesn't seem to work well on "win"dows (which I find amusing). I've looked into it extensively and there has a been a bug submitted to the knowlege base for 3 years now regarding this issue. I think it was an issue on win2k as well. No I don't get the BSOD (does that even exist anymore) but the damn thing freezes 1 in 3 attempts.

          The funnies thing is that I dual boot with linux and that "win"modem works perfectly. In fact, when I wasn't having to do any video editing in windows last year, I had an uptime of 215 days in linux.

          I conceed that some people have more stable installs with windows than linux, as long as you conceed that at least if those people WANT to take the time to fix their linux box, they could, while people like me couldn't fix my windows problem even if I infinite knowledge.

          So, I respectfully disagree with your post.
        • Okay, but... (Score:3, Insightful)

          by gillbates (106458)

          Where's the commercial OS worse than Windows?

          If my job as a project manager is to ship software on time and bug-free, why would I listen to Microsoft, which has done neither?

          Incidentally, my mother was a project manager for many years, and she managed to bring every project in on time, beating some deadlines by 50%. And bugs were simply not accepted - the project wasn't done until the bugs were corrected. Microsoft sets its own schedule, and they still can't ship bug-free software on time.

  • Dates (Score:3, Funny)

    by canfirman (697952) <pdavi25@ELIOTyahoo.ca minus poet> on Friday June 25, 2004 @10:53AM (#9527950)
    7. Never trade a bad date for an equally bad date.

    I guess that's proof that M$ programmers actually go on dates!

  • by tcopeland (32225) * <tom.thomasleecopeland@com> on Friday June 25, 2004 @10:54AM (#9527959) Homepage

    11. If you build it, it will ship.
    Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed.

    So true. And "in a public place [ultralog.net]" is definitely an important part of that - when a build fails, everyone should be able to see the compilation error.
  • by artemis67 (93453) on Friday June 25, 2004 @10:56AM (#9527972)
    does it have anything to do with "an infinite number of monkeys"?
  • Errrmmm... (Score:3, Insightful)

    by MancDiceman (776332) on Friday June 25, 2004 @10:58AM (#9528014)
    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

    Not being funny, but can somebody point out the last time Microsoft actually brough a team together and managed to deliver a project on time. Every major OS release, every service pack, every single project they have ever produced seems to have been delayed. They are the antithesis of "release early, release often" but then they having paying customers as opposed to us guys...

    Anyway, call my cynical, but I think I can find better sources on how to program than the Microsoft team.
  • by Anonymous Coward on Friday June 25, 2004 @10:59AM (#9528019)
    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.
  • by Hutchizon (696741) on Friday June 25, 2004 @11:01AM (#9528050)
    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.
    • You are correct, sir (Score:5, Interesting)

      by green pizza (159161) on Friday June 25, 2004 @11:15AM (#9528220) Homepage
      I would have to agree with you on this. In my experience, portability takes more time but (generally) ensures quality. What breaks on Linux might not break on Windows, exposing a potental problem. I find more bugs in my code by porting than with any other bug-hunting technique. Many are minor and often don't even affect the user in that exact revision of the app. BUT, it's these little things that cause major problems down the road when I modify or change certain features.

      For a commercial example, look at Quake 3, I think Carmack's portability (Win32, Linux, MacOS Classic [and later, Mac OS X]) helped a great deal. Q3A was fairly lightweight for its abilities and ran decent on just about any platform with a decent graphics card. (Now we're getting into hardware details, but I digress)
    • Portability takes time and money to implement.

      If its not an immediate requirement from your customers, including it in your estimates/costs is overcharging them. Good design makes porting much easier, and consideration should be taken, however if portability is not a requirement, simplicity of design and speed/cost of implementation should take precidence.

      This has nothing to do with locking in customers, or who wrote the article, it has to do with economics of commercial software development. Open sourc
  • by XeRXeS-TCN (788834) on Friday June 25, 2004 @11:04AM (#9528086)
    1. Release Early
    2. Release Often
    3. Listen to your customers

    I think Linus has proven the effectiveness of that one, and Eric S. Raymond [catb.org] happens to agree with me ;)

    • by stratjakt (596332) on Friday June 25, 2004 @11:26AM (#9528344) Journal
      That only works for free software.

      Release early - ie; when you KNOW it's unfinished.

      Relase often - ie; it's so full of bugs and unfinished you need nightly builds to work them all out. At this point, you're releasing forever because now you have yourself a moving target with no set "completion" point, or any goal you're trying to achieve.

      Listen to your customers - And if they complain just say "well it's free so fuck you if you dont like it". Seriously, no OSS projects "listen" to the customers.

      If they did "listen", Linux wouldn't be a monolithic kernel, so I could download binary drivers for my new video card without recompiling it. Guess what, nVidia or ATi are never going to want to open their drivers' source. Doing so would essentially give away all the IP they put into designing their GPUs. A month later, some fab is set up in taiwan producing Radeon clones.

      Samba would be able to function as an Active Directory Controller - it can't, and it's not even a project goal, NT4-style is apparently good enough, they haven't even plugged the gaping security holes in the old scheme MS did. Ie; you have to disable "require sign or seal" to join 2k or XP to a samba domain, essentially, you don't give a rats ass about verifying the authenticity of the MD4 password hashes that get bandied about plaintext on the network.

      Open source "works", but not all of the time, and not always how you want it to.
  • by revery (456516) * <charlesNO@SPAMcac2.net> on Friday June 25, 2004 @11:08AM (#9528145) Homepage
    All we know for sure that is that when Microsoft needs a new product, Bill Gates goes into his High Tower of Closed Sourcery with 15 sheep, Steve Ballmer, a technology company with an established product, and an Enya CD.

    When he emerges, two months later, the new MS product is ready for market, the sheep have been trained as VP's, and the technology company is dead.

    --
    http://www.livejournal.com/users/gymbrall/
  • What's with #6? (Score:5, Interesting)

    by Paulrothrock (685079) on Friday June 25, 2004 @11:09AM (#9528155) Homepage Journal
    Beware of a guy in a room.

    I do most of my good dev alone in a room. I even make deadlines! I used to work for someone who used to work at JPL in the 1970s managing software development. One developer would ride his Harley Davidson wearing a cape and goggles and lock himself in a room with the necessary hardware and ask that Twinkies and Coke be left outside the door. They didn't see him for a week, but the code was good. It was for the Voyager program, so we know it was good.

    There's a difference between not trusting an ex-frat boy alone in a room and a responsible software developer in a room. Treating everyone on a team the same just breeds discontent. If people work well alone and can be trusted to do so, don't make them waste their time in meetings.

    • Re:What's with #6? (Score:4, Insightful)

      by jkabbe (631234) on Friday June 25, 2004 @11:20AM (#9528273)
      Those people are good when they turn out wonderful code that works. But there exists the possibility that sometimes people like that will not turn out something that works. Or they will turn out something that works much later than planned. Locksing yourself in a room and not communicating doesn't make you a genius. And in a large project with tons of interdependancies you need to discover slips sooner rather than later.

      To use your example, what if this guy hadn't finished his code on time so it wasn't ready for the planned launch window? It's great that it worked out but many companies can't risk the possibility that it won't.
      • Re:What's with #6? (Score:5, Interesting)

        by Paulrothrock (685079) on Friday June 25, 2004 @11:27AM (#9528357) Homepage Journal
        Well, opening the door or setting deadlines is good. i.e. "I'm going to check on your progress in three days."

        However, sending out an email saying "Everyone needs to meet and sing kumbaya to built group unity and get together on how this thing works" is stupid. Give me a task, let me do it, and if it doesn't work, fire me.

        Or they could adopt Unix Philosophy. [uoguelph.ca] If a program does one thing well and stores all data in flat text files, working independently on programs is easy, since the formats are agreed upon.

  • 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.
    • by Otter (3800) on Friday June 25, 2004 @11:20AM (#9528279) Journal
      Huh? He's arguing against solitary development and for "They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures." and you're invoking Linus as an argument against him?
    • This is the danger of taking a line out of context. Really what that line means is a guy locked in a room for an indefinite period, and at some theoretical time in the future he releases his code to everyone else on the team and it magically works, and works well.

      It works fine if you're the only developer, it works horribly if you've got an entire team developing the software. People on a team need to touch base, and if there's just "guys in rooms" that aren't showing progress, taking criticism, etc, the
  • by schmaltz (70977) on Friday June 25, 2004 @11:11AM (#9528170)
    "1. Don't know what you don't know.

    It is essential not to profess to know, or seem to know, or accept that someone else knows, that which is unknown. Almost without exception, the things that end up coming back to haunt you
    ..."

    Did anyone else think of Rumsfeld's infamous mindfart (for which he won a Foot in Mouth award [plainenglish.co.uk]) --

    "Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know."

    Eerie.
  • Scarcely news (Score:5, Informative)

    by Tim Browse (9263) on Friday June 25, 2004 @11:12AM (#9528189)

    I recognise most of these rules from here [amazon.co.uk] - note the publication date.

    Quite a good book. The things being said are good. The way they are said is terrible. Very poor writing.

  • by Crash Culligan (227354) on Friday June 25, 2004 @11:14AM (#9528210) Journal
    12. Portability is for canoes.
    20. Establish a shared vision.
    These two grate on my nerves, and for good reason.

    #12 claims bluntly that supporting something becomes so much easier when you only have to support it on one platform. From one perspective there's a certain truth to that, and from another perspective it's laziness. But contrast it with #20.

    #20 says that the idea has to be shared as completely as possible between everybody in order for everybody to help out as best they can to making the idea a reality.

    "Things become easier to support and test if they follow certain specific guidelines, and with a common implementation, everybody can follow a given idea better." Sure, it looks good on paper, and it makes a fine creed for developers, but with Microsoft, that's where it comes to a screeching halt. Because out in the real world:

    Hey, nice standard! Mind if we grab it away from you and run this way with it?

    It's both weird and wrong seeing people in Microsoft talking about ideas and commonality of vision when in practice the company as a whole so copiously defecates (both buttocks blazing, as it were) on any standards that they don't already have a headlock on.

  • Breakdown (Score:5, Insightful)

    by mfh (56) on Friday June 25, 2004 @11:15AM (#9528221) Journal
    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.
    • Re:Breakdown (Score:5, Insightful)

      by richg74 (650636) on Friday June 25, 2004 @11:49AM (#9528615) Homepage
      "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.

      I think the 'triangle' is one of those seductive things that is almost right, and therefore is an open invitation down the proverbial garden path. Fortunately, it's not hard to fix. Let's take the elements in order:

      • RESOURCES This is certainly one of the key things that determines the outcome.
      • TIME Time (or the schedule) is critical. To paraphrase Fred Brooks in The Mythical Man-Month, more projects have failed for lack of calendar time than for any other single reason.
      • FEATURES This is the one that is wrong. What it should be is product quality. This is where, IMO, Microsoft (and others) frequently go wrong, by assuming that more features => better. (Notice that this really addresses the point that the parent post makes.)
      I think the focus on features, rather than on quality, is a manifestation of what I call "bookkeeping syndrome": something is adopted as a metric not because it's important, but because it's easy to count. Using quality as a metric is harder, because it requires actual thought about how the product ought to work, and about what really matters to the potential users.
  • Blind to portability (Score:3, Interesting)

    by amightywind (691887) on Friday June 25, 2004 @11:17AM (#9528240) Journal

    12. Portability is for canoes.

    And system software.

    Portable free software is in the process of dismantling his company. You would think he would acknowledge that.

  • by mjh (57755) <mark AT hornclan DOT com> on Friday June 25, 2004 @11:19AM (#9528261) Homepage Journal
    What strikes me about this article is how there's such an emphasis put on meeting critical dates, but that Microsoft is routinely late in delivering their software when they say they will.

    How much value should we give to these "rules" if they don't actually work?
  • by IWantMoreSpamPlease (571972) on Friday June 25, 2004 @11:21AM (#9528284) Homepage Journal
    is much like how sausages are made:

    Best not to know how.
  • by Fratz (630746) on Friday June 25, 2004 @11:28AM (#9528360)
    "While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations."

    Wow, the Mozilla developers could really learn something from Microsoft here. Maybe they should contact MS and ask how they can switch from a build environment that supports 10(*) or more platforms to one that just supports Win32.

    While they're at it, maybe the IE core team can help them out with how to introduce Mozilla features that allow arbitrary, hidden software to be easily and automatically installed on the user's machine.

    (*) Technically, I suppose the Mozilla team builds for 3 platforms (Win32, OS X, and Linux) which does probably limit the amount of QA testing required, but this is still usually 3x as many as the Microsoft people deal with, and the build system enables at least 7 more platforms on top of that.

  • by Dr. Bent (533421) <.ben. .at. .int.com.> on Friday June 25, 2004 @11:31AM (#9528398) Homepage
    12. Portability is for canoes.

    And system software. Even discounting the added development burden, with the addition of each additional platform the job of QA increases substantially. While clever QA management can minimize the burden somewhat, the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible.


    Wow...yeah, that's Microsoft alright. Don't bother writing software for anything but the One True Platform. Amen. Never mind the fact that Windows runs on...hmm, lets see...x86 and ummm...well. I suppose there might be a few others, but I couldn't tell you for the life of me what they are. Linux on the other hand...

    If you're writing a client side/GUI app, you can get away with this mentality. Try it on the server side and your product goes nowhere. I believe this is one of the reaons that Microsoft has had (and will continute to have) problems getting entrenched in the Enterprise computing market.
  • by wombatmobile (623057) on Friday June 25, 2004 @11:37AM (#9528457)

    Consider that Microsoft developed Windows (Mac), Excel (Lotus 1-2-3), disk compression (Stac), IE (Netscape) and the rest using other people's work as templates and the true value of #1, #2 and #10 is revealed:

    1. Don't know what you don't know.

    2. Get to a known state and stay there.

    10. Design time at design time.

    Then there's the way they "develop" products including MS-DOS, PowerPoint and Visio...

    3. Remember the triangle. resources (people and money), features and the schedule

    The lessons of Microsoft "development methodology" belong in university commerce and economics departments, not CS.

  • The missing rule (Score:5, Insightful)

    by Decaff (42676) on Friday June 25, 2004 @11:39AM (#9528479)
    22. Change direction then convince everyone that was the direction you were intending to go in at the start.

    Like with portability.... NT was supposed to be the portable OS, on MIPS, PowerPC, Alpha. But as that didn't take off, now 'portability is for Canoes'.

    No company can match Microsoft for blatant and unabashed hypocracy. This article is a good example.
  • by gillbates (106458) on Friday June 25, 2004 @12:02PM (#9528770) Homepage Journal
    the complexity of multi-platform support is beyond the reach of most development organizations. Place your bets. Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible. [emphasis mine]

    The first point is interesting; apparently, Microsoft doesn't know the majority of development work is multi-platform. I guess that in the Microsoft Universe(tm), if Microsoft can't do it, it can't be done... I am currently working on a rather large development project that will be used across at least two, if not three, major platforms. The overwhelming majority of developers must support multiple platforms because:

    • A vendor who writes an app that runs only on Windows risks Microsoft copying their idea and shutting them out of the business. Since MS almost never develops apps for non-Windows platforms, developing a cross-platform app is a hedge against MS stealing your ideas.
    • Cross-platform support is absolutely crucial for enterprise-level vendors. Most corporations want to leverage their existing server investments, and if you don't support the company's range of platforms, they won't be buying your application.
    • A large majority of internal development must be multi-platform because of legacy hardware.(yes, w2k and Windows98 count as separate platforms from a dev perspective). Just because your company has upgraded to Linux doesn't mean that there isn't a legacy Windows server lying around somewhere.

    And the second point? Granted, Linux may be able to do multi-platform support rather well, but anyone who demands multi-platform support from Microsoft will get laughed out of the boardroom. It's not like they're going to care; you aren't spending their money to develop your application, and if it doesn't run on different platforms, it only increases their monopoly.

  • by Gyorg_Lavode (520114) on Friday June 25, 2004 @12:10PM (#9528829)
    3. Remember the triangle.

    There are only three things that you are working with as a development manager: resources (people and money), features and the schedule

    Funny, I've always heard it as Cost-Schedule-Performance. It is another manifestation of the fundamental difference in thinking by microsoft that features should replace performance, or are synonymous with it.

  • by Anonymous Coward on Friday June 25, 2004 @12:35PM (#9529160)
    There's so much bullshit in this article, you won't believe. I don't know who this guy is, but any MS developer worth his salary would laugh him out of his office over that "Don't go dark" thing. That's the only way to get anything done at MSFT. If you participate in all the meetings that are scheduled for you and get "buyoffs" from everyone you will NEVER get anything done. So it goes like this, you participate in the meetings at first (to make you look good when review time comes) and then you go PITCH BLACK, not just dark and deliver the code. It's always easier to get forgiveness than to get permission.
  • 10 other rules (Score:5, Insightful)

    by tootlemonde (579170) on Friday June 25, 2004 @12:47PM (#9529324)

    These rules of egoless programming have been circulating on various sites: [com.com]

    The Ten Commandments of Egoless Programming

    1. Understand and accept that you will make mistakes. The point is to find them early, before they make it into production.

    2. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.

    3. No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.

    4. Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.

    5. Treat people who know less than you with respect, deference, and patience.

    6. The only constant in the world is change. Be open to it and accept it with a smile.

    7. The only true authority stems from knowledge, not from position.

    8. Fight for what you believe, but gracefully accept defeat.

    9. Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.

    10. Critique code instead of people -- be kind to the coder, not to the code.

    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.

  • by MenTaLguY (5483) on Friday June 25, 2004 @12:58PM (#9529476) Homepage
    I guess there's a certain truth to what he says, depending on how you approach it.

    The thing is, you really _don't_ want to be in the business of having to worry about platform-specific concerns for more than one platform in your own code.

    If you try, you'll either end up essentially writing your own meta-platform (building and debugging it from scratch, consuming development time better spent elsewhere), or your code will become a mess of #ifdefs and specializations which can only ever be built or tested on obscure platforms (meaning most platforms will always be moderately broken).

    What you want to do is pick a platform that lets you run on a range of systems -- i.e. "leave it to your system software".

    Inkscape's "platform", for example, is for the most part not POSIX nor Linux nor Win32, it's Glib/Gtk+/Pango/Gdk + libxml + STL.

    We still have a number of platform-specific subclasses and #ifdefs (many inherited from Sodipodi), but we're actively working to reduce (ideally eliminate) them.

    For example, most recently (in CVS), we replaced the typography subsystem we inherited from Sodipodi with a little bit of glue code on top of Pango.

    In the process, we gained a lot of features that Lauris never had time to implement or debug in Sodipodi's private typography library, like using the kerning information specified in fonts, and the hardest parts of support for rendering "interesting" non-Western scripts.

    Just be sure that the set of libraries (your platform) which you write to is widespread and well-tested on the systems you care about.

    I guess given the systems David's employer cares about supporting, his choice of Microsoft platforms shouldn't be altogether surprising.
  • by wintermute42 (710554) on Friday June 25, 2004 @04:27PM (#9532062) Homepage

    rather than deeply.

    The Microsoft interview style is to ask the interviewee a constant stream of white board programming problems and throught puzzles. While this selects people with a certain level of intelligence, it also selects people who can think rapidly "on their feet".

    Perhaps the end result is to select a homogenious population of "Softies" think fast, settle on an approach and then hack it into code. Where a better approach to product development might be to think about the design, think about some alternatives, discuss the design and then implement it.

    Many people agree that Microsoft software evolves once it has been released. The common example being a first product that is inadequate, buggy and slow, eventually evolving into something that becomes popular. Perhaps this is a result of a culture of programmers who believe they are very smart (after all, they survived the Microsoft interview), think fast and then entomb their initial half-baked design in software.

1 + 1 = 3, for large values of 1.

Working...