Diederik Beker week 3 assignment - matthijsbos/swe2013team5 GitHub Wiki

The Microsoft Way of Software Development By Maarten Jager & Diederik Beker 10182527 & 10190848 Source: http://blogs.msdn.com/b/david_gristwood/archive/2004/06/24/164849.aspx Microsoft After the extremely useful experience of digging through the logs of a failed project 2 weeks ago, this week we will have an equally interesting experience: looking at a success story. I've chosen Microsoft as the topic, because of it's huge effect it has on the world and also because it is one of the biggest software companies of the world. This is clearly not a coincidence. So why is Microsoft such a success?

Jim McCarthy Considered to be one of the big inventors of the Microsoft way of software development, Jim McCarthy is the main source for this article. In 1995 he wrote and published an article called "21 Rules of Thumb for Shipping Great Software on Time". This is was after he had been working almost a decade at Microsoft where he had developed most of his ideas and where he made many changes in the software development architecture. I will go through some of the most important of his "rules of thumb" and try to explain while they are so important to a successful project in my opinion.

"Don’t know what you don’t know" The basic meaning of this sentence is that you shouldn't pretend to know something which you do not fully understand. Nobody can know everything there is to know about a project, meaning that you should never be ashamed of your ignorance. A bigger fear should be leading people to think you understand something, which will lead them to think you understand it, which will cause you to miss potentially crucial information.

"Get to a known state and stay there." This point is concerning Quality Assurance (QA) in software development. QA should know the quality of the project at all times. And after you have reached an acceptable quality rating you should never downgrade but keep up a good documentation and a comprehensive buglist.

"Use zero defect (ZD) milestones." First up, zero defect milestones are not milestones where the software is not allowed to contain bugs. Zero defect milestones are documented on beforehand so that when the milestone comes near everyone can clearly see which parts of the project are behind on schedule and the parts which are falling behind can be helped back up.

"Never trade a bad date for an equally bad date" When you are reaching the end of your project and you are going to fail your deadline, you know way before the deadline. But this does not mean that you can make a better assumption for a next deadline. As long as you are incapable of setting a good deadline, don't. Once you have failed one deadline it is important you keep the next, to keep up your credibility and your team's motivation.

"Low tech is good." A smaller effort is almost always more desirable than a larger one. Good software requires that we value an understood solution much higher than one we may not fully understand.

"Conclusion" I hope this helped understand why Microsoft works. Having a motivated team that understands some fundamental rules will yield you a much higher success rate than disorganization and blind coding, and in my opinion Microsoft does a great job at keeping up their own fundamental ideas.