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

2 of 816 comments (clear)

  1. Re:My post by PhxBlue · · Score: 5, Informative

    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.
  2. Re:My post by NanoGator · · Score: 5, Informative

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