Slashdot Mirror

← Back to Stories (view on slashdot.org)

How Microsoft Develops Its Software

Posted by michael on 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.'"

17 of 816 comments (clear)

  1. My post by andy55 · · Score: 4, Interesting

    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.

    --
    G-Force music visualization
    1. Re:My post by Anonymous Coward · · Score: 5, Interesting

      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.

    2. Re:My post by Anonymous Coward · · Score: 4, Interesting

      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.

    3. Re:My post by Decaff · · Score: 4, Interesting

      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?

    4. Re:My post by ezavada · · Score: 4, Interesting

      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.

    5. Re:My post by mcrbids · · Score: 5, Interesting

      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.
    6. Re:My post by danheskett · · Score: 4, Interesting

      1. I referring specifically to the part about them putting more people out of business than they employ. That is not proven, and has never been argued in court. They have comitted infractions and crimes and torts, and have dealt with them all.

      2. Your descrption of what happened is false. The Justice department didnt just decide to drop the case. You made that up. The choose to not pursue a breakup order - that's a remedy - after losing several appeals. The political system is legal. FYI.

      3. Sadly, it is you who makes no sense. You claim MS superior software only when sabotaging someone else's software. That is absurd and provably false. However, it is irrelevant. 4a. Time is valid argument. Do you hold Volkswagen of 2004 responsible for actions of Volkswagen of 1944 in moral sense? I don't. It is reasonable to expect that after a given period of time things change within a corporation. This is true at Microsoft. They have a major management shakeup since the anti-trust trial. Or did you not notice that Bill Gates was ousted as CEO and President of Microsoft?

      4b. Settling is a perfect reason why you should let it go. They admitted liability, paid a settlement, and that's it. The case cited has no relevance on today's project management techniques. None whatsoever.

      4c. The act WAS UNIQUE. Microsoft did not sabotage any other version of DOS to be incompatible with Windows. Just one - DR-DOS. They did not cause other purposeful incompatibilies with Windows 3.x and alternate DOS's. It's just that simple. If you have other cases to cite, than speak up. What you seem to be suggesting is that comitted similiar crimes with other products and software makers. But the other cases you will likely cite are vastly different. The Java situation, the Netscape scandal, etc are TOTALLY DIFFERENT ACTS, falling under TOTALLY DIFFERENT legal definitions.

      5. Of course my point was good. Microsoft today - both managerially and technologically - is completely different from the company it was in the early 1990s.

      In conclusion, the statement "Let it go" demonstrates ignorance, complacency and stupidty
      Hardly.

      You are basically saying it is OK to commit crimes. A better statement would have been.
      I am saying that as critique of Microsoft bringing up a case that is over 10 years old, references completely obslete products, involves defunct vendors, was settled in court, and which is unrelated to anything at all to do with the article is a crappy proposition. It shows a general status of being out-of-touch with the situation. It shows a patetically reduced sense of scale. It shows that you equate an action that was eventually determined to be worth $23M to be the only deciding factor in the quality of a company that employes 50,000 and has an annual revenue in the high tens-of-billions.

      "That crime has been paid for and irrelevant to this discussion". That would have been accurate, intelligent, fair.
      If you think it's irrelevant to this discussion, why did you feel compelled to post?

  2. Professionalism by Some+guy+named+Chris · · Score: 4, Interesting
    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
    1. Re:Professionalism by mmusson · · Score: 5, Interesting

      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
  3. #11: Build it every day by tcopeland · · Score: 4, Interesting

    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" is definitely an important part of that - when a build fails, everyone should be able to see the compilation error.
    --
    The Army reading list
  4. Re:Microsoft develops software by Mz6 · · Score: 4, Interesting
    With its eye's closed...

    If that's the case, just wait until someone comes along and open them. Microsoft will be the single biggest software corpora... err wait a second.

    In all seriousness though, they are actually starting to open their eyes now and realizing that security is going to play a huge role in their continued success to develop software. I think they will still continue to be on top so long as they can evolve. So far they are beginning to... Let's look.. First was a more secure approach to computing, now they are starting to get more serious about searching techniques...

    --
    Hmmm.
  5. Portability is for canoes? by Hutchizon · · Score: 5, Interesting

    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.

  6. What's with #6? by Paulrothrock · · Score: 4, Interesting
    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.

    --
    I'm in the hole of the broadband donut.
    1. Re:What's with #6? by Paulrothrock · · Score: 4, Interesting
      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. 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.

      --
      I'm in the hole of the broadband donut.
  7. The Whole Difference between Microsoft and Linux by Bandman · · Score: 5, Interesting

    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!
  8. You are correct, sir by green+pizza · · Score: 4, Interesting

    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)

  9. I've worked there, and I must say by Anonymous Coward · · Score: 4, Interesting

    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.