21 Rules of Thumb - How Microsoft develops its Software
I will be presenting a session at TechEd in
So, just how do you get teams to work together successfully? I’ve written a few articles on it, interviewed people at Microsoft about it, and witnessed it first hand with teams inside and outside Microsoft. Jim McCarthy, who I have met and heard present, whilst at Microsoft, in the C++ team, wrote an article entitles “21 Rules of Thumb for Shipping Great Software on Time” (which I have enclosed at the end of my blog in its original form) and followed it up with a book “Dynamics of Software Development”. My session at TechEd is largely based on this article, and so if you are inspired by this session, then the best thing you can do is buy the book (and no, I don’t get any commission!) and start using it. (He also has a newer book “Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision” which you may want to look at as well)
The other topic I cover in my session is the Microsoft Solutions Framework (MSF). If Jim’s contribution is the anecdotes and rules of thumb, then this is the more formal documentation from Microsoft. MSF has been an ongoing initiative within Microsoft since 1994 to document the best practices that the Microsoft product groups, customers and partners, have used in the software development process. I was one of the first MSF trainers in the
All the information you need on MSF can be found at http://www.microsoft.com/msf , including an MSF 3.0 overview white paper, and details of the team and process model, which are at the core of MSF. There is also an update on how Visual Studio 2005 Team System, which we recently unveiled at TechEd in
21 Rules of Thumb for Shipping Great Software on Time
Jim McCarthy, Microsoft Corporation
Shipping great software on time is a difficult but not impossible task. Elements you think would count the most count for very little. Development methodology, process, technical prowess, excellence of tools and depth of project management skills all influence the outcome of a software development project; but nothing indicates success as much as the manager’s ability to focus on a few critical and conceptually simple things. These things can be expressed as rules of thumb.
I enumerate twenty-one of these rules of thumb. Pick a handful (or so), apply them, and your project will be more likely to succeed. I lump them into three groups: "Shipping," "Great Software," "On Time". Duh. I cover them in a different order, because the concepts build a bit.
On Time
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 are things you pretended to understand but didn’t early on. At virtually every stage of even the most successful software projects, there are large numbers of very important things that are unknown. It is acceptable, even mandatory, to clearly articulate your ignorance, so that no one misunderstands the corporate state of unknowingness. If you do not disseminate this "lucid ignorance," disaster will surely befall you.
Human nature is such that we dislike not knowing things that are important to our well being. Since there is so much we don’t know in a software project, the nearly universal tendency among developers and their managers is to gloss over or even deny altogether the extent of their ignorance. You should reward and treasure those who consistently make themselves aware of the list of relevant things that are currently unknown. It requires mental and psychological strength to resist the normal human cravings for certainty and order. It especially difficult to believe in uncertainty when things have a veneer of orderliness, which is often the case. Pseudo-order is a maladapted defense against uncertainty.
The organization surrounding you will undoubtedly abhor uncertainty, would infinitely prefer pseudo-order and will make countless attempts to magically convert your ignorance to knowledge. Your job is to make uncertainty an unshakable fact, and to coerce the reshaping of the surrounding organization to cope with the uncertain situation. The organization must learn to thrive in an uncertain environment for its own well being.
You should expend a great deal of effort making sure that all the people on the project are aware of their ignorance rather than naively converting it to falsehoods. Bear down on them until they realize they haven’t comprehensively assessed the unknowns. In the successful project, this is much easier in the early stages, or during times of change. This is no time for niceties. People ultimately prefer success even if disillusionment is a prerequisite.
2. Get to a known state and stay there.
The function of QA is to know (and articulate) the quality of the product at all times in the development cycle. This should be achieved by abbreviated, repeatable tests conducted daily, and full product sweeps conducted weekly or biweekly.
It is not properly the job of QA to determine when a product is ready to ship; rather, the moment of shipworthiness in a product development cycle is evident to everyone involved, and is non controversial. This is because shipping has been the goal of the entire effort. Crossing the finish line, while it has intangible emotional and definite financial rewards, is no surprise when you’ve observed every single painful step toward it.
The only reason you’ve been able to make these micro-observations is because you got to a known state and stayed there, and your QA is how you did it.
Achieving a relatively accurate view into product status is a very challenging goal, requiring a highly motivated and competent QA team. It is also a pre-requisite for success. Many software development organizations have rudimentary or no real QA assets, and there is little that can be done for them until they make the appropriate investments in creating a modern development organization.
A known state consists of all components having accurate status information at a given point in time. You know that it’s accurate because the status has been tested by QA.
A developer articulating the status of his/her component is an exercise that does produce information, but if it happens to communicate the component’s status, it is only coincidental. This is someone else’s job.
Status should consist of a comprehensive listing of tested and missing functionality, bug count sorted by severity, bug arrival rate, bug fix rate, projected total bug count, and other vital metrics.
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. Changing one has an impact on at least one other axis, usually two. It is a simple enough matter to mentally run through the sides of the triangle, or force others to do so, when discussing any part of it. Since the people, the product or the schedule is almost always what you’re discussing, this means that you must constantly envision the triangle. This leads to the most fruitful line of thought.
4. Don’t go dark.
Some features have long development lead times, months or even years. Yet slips usually happen a little bit every day, and must be compensated for a little every day. This means that the granularity of development tasks must be such that deliverables are achieved at intervals sufficiently small that slips can be compensated for. A week is a long time to go without knowing what is happening. While micromanaging is always a danger, and will certainly be an accusation leveled against you from time to time, if the goal of the project is to ship great software on time, and if everybody accepts that goal as uppermost, they generally enjoy the chase. Team interdependency is also a powerful motivational force.
5. Use zero defect (ZD) milestones.
Organize the project around the concept a reaching milestones with zero defects. Zero defects does not mean that the product does not have bugs, or missing functionality; it means that the product achieves the quality level that had been set for that milestone. The product is tested to that effect. The essential point of ZD milestones is that nobody makes the milestone until everybody does, and nobody leaves it until everybody does. This enables the team to discover what aspects of the project are in trouble. Load balancing can occur. Awareness of unknowns rises.
At a milestone, the team and its leadership also have the opportunity to perceive the whole project status simultaneously, to draw conclusions about erroneous practices, to remedy bad design decisions and to reorganize for peak performance. Shipping is just the final milestone. Though the external organization cares most about shipping, which adds special pressure to that milestone, the team develops extraordinary focus and introspection about each and every milestone.
6. Beware of a guy in a room.
This is really just a special case of "Don’t go dark." Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time. Without regard to their individual brilliance, before investing a developer with a significant assignment, it is essential that they understand and agree with the type of development program you intend to run. They must be capable of performing on a team, making their work visible in modest increments and subjecting it to scrutiny as it matures. Some people find this intolerable, and though there is a role for people of this disposition in the software world, it is not as part of a team devoted to shipping great software on time.
There are many pathologies at play here as well as certain healthy patterns of creative behavior. One pathology is a type of savior complex that cannot be satisfied without blowing every single deadline but the last, and then emerging victoriously with a brilliant piece of work five minutes late. A more healthy pattern is that of the true innovator who is truly designing something great, but who has no personal resources left over for anything but the work at hand. Every ounce of psychological, emotional and intellectual energy is being consumed in the work itself. Teamwork, in this case, is an insignificant factor to a person immersed in this sort of creative experience.
But whether or not the cause is healthy or bogus, the results are uniformly fatal to the professional development organization. Beware. Extricating yourself from this trap is nearly impossible.
7. Never trade a bad date for an equally bad date
Generally, you know you’re going to be late before you know when you’re going to be done. Further, everybody on the team and everybody they come in contact with knows you’re not going to hit the schedule. The pressure to reset the end-date (or the milestone date) is enormous. Even though your information is obviously better now than when you originally set your goal, it is probably insufficient to make a new schedule. This is because with each slip, you and your team are spending your credibility. It is essential that after a slip, the next milestone be hit. This is so the team believes in their ability to manage the project, and so that the reserves of credibility are rebuilt for later consumption.
It is difficult to say precisely and in all cases when you should "officially" slip. A good general rule is that the schedule should be reset when the total extent of the slip is known for each component, the causes of the slip are understood, and remedies are in place. Usually, this takes the effort of the entire team and its leadership, and must be an explicit, focused activity. After this level of work is achieved, create a new, closer and more conservative milestone which the team is very likely to hit, and promulgate that. Avoid just sliding the schedule out. Your near-in milestone should be extremely realistic, and uncertainties about later milestones will remain and should be highlighted.
8. When slipping, don't fall.
Slipping is what happens when information that was unknown becomes less unknown. Though slipping is widely perceived to be a "bad" thing, it is the symptom of a good thing, as a fever is the sign of the body’s immune system at work. Although it is undesirable to have so many unknowns that slippage occurs, it is not an unusual situation, and may even be the norm. This is because much of contemporary software development is essentially experimental, i.e., new platforms, new operating systems, new programming technologies often coalesce on new programming projects to create a high degree of uncertainty.
In order to avoid calamity, certain measures should be undertaken in connection with a slip. Ideally, one or more of the pre-identified unknowns caused the slip. It is important that everybody involved understand that the risk to the schedule had been known previously. Alternatively, it is essential to understand how the unknown/s had come to be overlooked. How this gap occurred should become part of the group knowledge for future success. Also, determine whether or not people are working on the correct things. Often, slips occur because members of the team become occupied with features of marginal consequence, or features that are not part of the core product message.
If the slip was a surprise, your communications system is broken, and dramatic communications efforts are required. Large amounts of detail must be brought to the surface for everybody on the team to see. Assess the reality of all current near-term estimates. Expose denial. Team defensiveness will have to be pushed back for the purposes of group learning. Slips reveal your team’s weaknesses, presenting a good opportunity for insightful management and mentoring. Make sure that each individual who has a role in the slip receives the needed guidance and support.
Slips are also an opportunity to re-evaluate the feature content and resource loads, generally with an eye toward decreasing the features and shoring up weaker areas on the team.
A good slip should be a net positive.
9. Low tech is good.
A smaller effort is almost always more desirable than a larger one. Shipping great software on time requires that we value an understood solution much higher than one fraught with unknowns. Keep in mind that customers would almost always rather see progress than promises.
10. Design time at design time.
The product will ship when the design can be shown to be implemented. Developers and their managers often ignore the exigencies of time when creating a design. Instead, they should consider the implementation time as a critical design element. When evaluating alternative design decisions, the one that takes longer to implement is consuming more time and should therefore be disadvantaged in comparison to the alternative. This must always be weighed. Often, when appropriate design value is awarded to timeliness, implementation time can be substantially compressed.
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.
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.
Great Software
13. Enrapture the customers.
Most software is a renewal business. Customers buy multiple releases over a relatively long period of time. As a consequence, the market has a deep understanding of your software and its flaws, and your organization and its flaws. Often, the market has grown uncomfortably dependent on software that doesn't meet its needs. In many software situations, customers spend hours per/day uncomfortably shoe-horning their lives into your product. As a consequence, they crave your understanding, and will respond enthusiastically to the least sign of it. Normal success, meeting customer expectations, means to improve the most outrageous and flagrant violations of their needs from version to version. They will likely stay with you if you are faithful about that, though they may well be sullen if not mutinous.
Great software, however, requires that you pivot your entire technology so that it flows in the direction of their deepest needs. You must innovate in ways that clearly affirm their inarticulate desires. Surprise them by articulating and resolving in your product concerns and fantasies that heretofore had been rumbling about only in their pre-conscious. The fantasies of the market are generally centered on issues of empowerment, control and security. The market wants to be able to do things with its computers that it currently can't. Customers often find they can't even publicly admit these needs for fear of computer illiteracy. They derive value and security from being able to apply your software. To admit that they can't do what they want to do requires a sense of security beyond most customers’ reach.
Market understanding is the foundation of great software. To repeatedly demonstrate through a series of two or three releases that you genuinely understand the market will result in enormous customer loyalty and brand equity. You will be viewed as the source of the market's empowerment. They will be rapturous.
Gaining this understanding and embodying it in your software requires skill, tenacity and creativity. You must recognize the central market need and organize all your technology and communications efforts in the direction of satisfying that need. While good listening, careful observation and concept testing will be required for you to identify the correct need, addressing it in your product will have these effects:
1. It will appeal to the customer's sense of security.
2. It will extend the customer's control.
3. It will be such that if all else were dropped from your product, but the central need was met in unique ways, the product would be compelling.
4. It will clarify your product messages.
5. It will simplify your product's use.
14. Remember one thing: Unity.
Unity is the master principle of great software. Each element in the product is necessary to the value of the whole and all necessary elements are there. Since everything you need is there, you aren't tempted to go beyond the present experience, and since nothing is there that isn't required, your absorption into the world of the product will not be disturbed. Unity of purpose and unity in execution should be the hallmark of your team. Unity is achieved in a product by following certain creative principles (#15-#19, below), whether intuitively or consciously.
15. State your theme.
Theme is the dominant idea that constitutes the basis of the design. All of the values of the product must stem from the theme. In order for people to comprehend the theme, it must be rendered with surpassing clarity. Theme is analogous to purpose. The more specific the purpose, the greater the effect. Having a theme to the product will require that you eliminate or at least minimize orthogonal values. This is painful and involves risk.
16. Vary it.
Variation is the theme restated and elaborated in slightly altered and embroidered ways. Variation is the means by which we intensify the user's comprehension and appreciation of our theme, and leverage his/her growing consciousness in new ways.
17. Balance it.
Allocate appropriate emphasis among the various elements of the product. If a key component supporting the theme, encountered every time the thematic function is enacted, is weak, the theme is weakly stated and the product will be justly criticized.
18. Evolve it.
Evolution is when earlier parts determine later parts. Lessons learned in one part of the product apply to the others. Things progress in a way that is pleasing. Outcomes, if not predictable, are satisfying because the product foreshadows them in countless ways.
19. Your product should be a hierarchy.
Hierarchy is when the elements of the product gain attention in proportion to their importance. Closely related to the property of balance, hierarchy provides a means for establishing and evaluating balance. If the theme is the top of the hierarchy, elements at the next level have balanced value with respect to each other, all equally supporting the thematic function, and so on throughout the rest of the hierarchy.
20. Establish a shared vision.
It seems absurd to even have to state this, yet it is perhaps the most difficult thing of all to achieve. Everybody on the team must know what they are trying to achieve, what the finished product will look like, what the basis of the product strategy is, and when they must deliver it in order for it to have its intended effect. Contradictory visions must be resolved and unified. Harmonious purpose must be achieved, or greatness is out of the question and even shipping becomes infinitely more complicated.
Shipping
21. Get the team into ship mode.
There is a moment on every development project when it is ideal for a team to enter ship-mode. Ship mode is a high performance period characterized by efficiency and determination. It is a period of flow. Before a team can enter ship mode, several pre-requisites must be satisfied.
1. Shipment must be the next milestone.
2. Everybody (or nearly everybody) must believe that achieving the milestone is possible.
3. All members of the team must understand precisely what they must do prior to shipping. All unknowns are factored out.
4. Management must lead the team to ship mode by entering ship mode first. That is, superfluous management hoo-ha is eliminated, the manager’s awareness of detail climbs, fire-drills and other de-prioritizing activities are eliminated entirely and tremendous focus is brought to bear.
5. The team must desire to ship. Generally, a complete awareness of the effect of shipping (or not shipping) will create desire.
The team becomes especially vigilant about thinking things through, and looking for traps. Check-ins are made with extra precaution. Stabilization of the product is the principle goal. All development is complete but for bug fixing.
The endgame, the last stage of shipmode, is different yet again. It is conceptually a very simple exercise. There is a list of activities. When every activity on the list is complete, you ship. Though the list might have hundreds or thousands of items, it is still just a list. There is no time for any effort that does not contribute toward completing the items on the list. Everybody is expected to complete their items as promised. As unanticipated items arise, after appropriate resistance, they are put on the list.
A daily meeting should be established, with final decision-makers in attendance. Agenda is ad hoc, assembled at the beginning of each meeting. No item is postponed that can be handled now. The team is aware that all issues can be brought to this meeting for expeditious remedy. Management is involved, leading the team toward their goal.
The goal is an acceptable quality level at ship time. Only showstopper bugs should be addressed at all. Showstoppers are bugs that will either effect more than a handful of users or will cause unacceptably serious errors. Cosmetic changes, performance enhancements, new functions are not appropriate changes. The purpose of beta feedback during this period is to prove there are no showstoppers, provide advance warning of unanticipated market reaction and provide input to the next release.
Understand the range of quality that is acceptable to your customers. How many low priority bugs did your product ship with last time? Was it a problem? Are the customers better off with this product including this bug? Since destabilizing the software is more of a problem than most bugs, be very careful about which bugs you fix. This is why we have "ReadMe’s" and bug lists.
Shipmode is basically a succession of daily milestones climaxing with the product’s shipment.
Many thanks to the staff and management of the Visual C++ Business Unit at Microsoft, from whom I learned and plagiarized these ideas.
posted on Thursday, June 24, 2004 5:24 PM
Feedback
# Software Development Rules of Thumb 6/24/2004 2:34 PM Hello??? .... is this thing on??
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/24/2004 10:32 PM Alex Campbell
Thank you for a very interesting insight into how Microsoft approaches this!
The Slashdot crowd might disagree, but I would say that this approach has turned out fantastic products for MS.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 3:18 PM Peter da Silva
Reading this helps me understand many of the frustrating limitations of Microsoft software out in the real world. For example:
Portability is for canoes (and system software). "Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible."
Of course, for people outside Microsoft applications like Office and Internet Explorer *are* system software. To Microsoft, they're the product, and portability is something to be avoided, but to us they're what we build our own software on: how do *we* build great software for the Microsoft platform if Microsoft's developers refuse the same support they demand of their software division?
Remember the chant... "Developers, developers, developers?" We're all developers, and even if all one of my users is developing is a web page they don't want to have to fight Microsoft to make it work where *they* need it.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 3:42 PM Chris Vaughan
Having been the "Guy In The Room" on more than one project, I can agree with the dangers in that mode of operation. In my case, there were two main contributors to that. The first contributing factor was physical isolation. I've been seperated from my team by as much as 3000 miles. Secondly, I've been a member of a team where programming in isolation was embraced by the whole group. Nobody wanted to be accountable to anybody else.
Great programming teams are fun to be on. The quest towards a goal grows people together. The opposite sucks, and makes work drudgery.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 3:44 PM Andy O'Meara
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. As 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 beleive possibilty (3) is the case.
Andy
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 3:44 PM Chris Vaughan
Oh, yeah. I forgot about the article I wrote in my blog about that.
<a href=http://blog.grump.org/article/22/depression-isolation-and-the-career-programmer>Depression, Isolation, and the Career Programmer</a>
# Know thy enemy 6/25/2004 3:58 PM Jim McKeeth
As a software Developer on the MS Windows platform we are both cohorts and competitors with Microsoft. Rather you agree with the Microsoft development philosophy or not, this is useful information.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:01 PM gary niger
Hey I did a presentation last year which covered similar points.
Here you go, http://www.meatbox.net/~lysol/lm.swf I hope you find it useful
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:02 PM 'article?' - come on!
this sux
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:02 PM timecop
dear sir, please stop spewing crap on the internet.
just because you have a computer and notepad.exe, that doesn't mean you need to be publishing your tripe for everyone to look at.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:03 PM SickMind Fraud
Unfortunately, at least on the marketing side, they tend to over promise and underdeliver, when it should be the other way around.
But then, some folks make a specialty of not delivering real products at all, <a href="http://psywatch.blogspot.com">as seen in certain non-technical fields</a>
It could be worse.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:08 PM duh
"this approach has turned out fantastic products for MS."
MS has absolutely NO "fantastic" products.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:14 PM R Clint Ellis
The author uses the acronym QA (Quality Assurance) to mean Quality Control or simply Testing.... Quality Assurance is process focused, not product focused. QA should verify that design conforms to specs, coding conforms to design, and testing (from unit to system) actually tests for coded/designed/spec'ed functionality.
I've seen this done the author's way (which means that 'QA' ends up in pointless arguments with designers) and my way, where engineers do the engineering and testing, and QA makes sure that engineers do what engineers are trained to do.
Clint
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:17 PM timecop2
"dear sir, please stop spewing crap on the internet.
just because you have a computer and notepad.exe, that doesn't mean you need to be publishing your tripe for everyone to look at. "
dear timecop, please stop spewing crap on the internet.
just because you have a computer and an internet connection, that doesn't mean you need to be posting your tripe for everyone to look at.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:14 PM unimportant
Great philosophy. So why is it that MS never bothered to implement it again?
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:15 PM Someone
" MS has absolutely NO "fantastic" products."
Right, because you're the one rolling in billions? Greatness is certainly subjective, but theirs has a lot more tangible evidence.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:26 PM Herses
I've always just followed one rule all along: K.I.S.S.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:29 PM warhammer
Great software ? It's brilliant.MS software is so brilliant I moved all my servers off it and onto Linux. Now I don't have to worry about licensing , viruses,huge amounts of security holes and Blue screens. It's a great toy though.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:30 PM Peter
Why do i wait 30+ seconds to forward an email from OUtlook 2003. CPU usage 1% - Delay 30+ seconds? Why do my Signatures always get messed up so that they no longer show up for email i select. Why do my Signatures cause other email clients to have to scroll 15000 lines to read my email because for some reason the signature refused to break. Why does MS Word XP crash every single time it opens up. Why Does Office One Notes just stop displaying "expanded Pluses" and stop showing edited changes until a restart.
I fail to see how i could classify Software that causes a 30 second delay, or any of the other afore mentioned things "Fantastic" software or software that I feel proud to have purchased and owned.
Software developing is going backwards imho. They concentrate on different things and throw a few gradients in there and then call it a "Fantastic Product" leaving behind bugs, flaws and lack of features that leave one wondering why one spend $300- $900 onj a product
The Results from the URL have nothing to do with this conversation but it would be nice if it did.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:30 PM Eric
I think the "sour apples" on this message board probably haven't been involved in real software development. It can be such a challenge to get a team on the right track to have predictable results in the end.
Feature-rich software such as MS-Office is a collasal achievement -- I don't know if I would have built the software the same way, but packing that many features into a product is unheard of in any other arena. Can you imagine a VCR or a Car with that many features? I cannot think of any other software package that has that many features that is intended for use by the general populous.
Thanks for your insight into Microsoft's development process, and I will be sure to share this with my team.
Thanks,
Eric
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:31 PM nrm
What would you say to the contention that the 'to-shipping' phase (number 21 above) would seem by your characterisation of it to be closer to a death-march than a planned, controlled delivery process?
The only reason I say this is because I have read Steve McConnell and he seems to suggest that the shipping phase should be no different than the other phases, otherwise the organisation has lost control.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:32 PM Tom Hudson
Re: 5 ... Zero defects does not mean that the product does not have bugs, ...
<p>
I guess this is the opposite side of the coin of "if you can't fix it, feature it", which gave us the "it's not a bug, it's a feature" mentality. A bug is a programming error. Zero defects means zero bugs, zero errors. To even try to argue anything else is to lie.
<p>
Re: 6. Beware of a guy in a room.
<p>
So, what about Philippe Khan? 1 guy. 1 motel room. 6 weeks. Result: Turbo Pascal, complete with IDE. Borland then went on to grab 2/3 of the PC compiler market in the 80s with Turbo C.
<p>Most of the stuff we depend on started with one guy in a room, and an itch to scratch. Linus Torvalds for linux, for example. Larry Wall for perl. A couple of guys in a garage for Apple. php. oython. vim. emacs. sendmail. Heck, even Apache started out as "a patchy server". All the s/good/great/ stuff started out with one or two guys in a room and an idea.
<p>
The article is self-serving and unrealistic, to say the least.
<p>
Overall,
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:38 PM Software Manager
Terrific writeup. You've been slashdotted, so expect a huge amount of knee-jerk religous anit-microsoft zeal in the comments (sadly some of Microsoft's biz/marketing strategy gets reflected poorly on an otherwise great engineering group). From a Silicon Valley engineering manager's perspective, you're spot on - thanks for making a cohesive summary.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:39 PM Frottage
Actually I'm more interested in where+how MS develops its software. From what I understand, MS has a global development team. Do different cultures interpret the "21 rules" differently? Does MS vary its rules for different cultures and if so, how?
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:42 PM TFOAE
"Portability is for canoes"
Well, tell that to projects that used pSOS until Wind River bought them, then had to start thinking about vxWorks....
BT, DT, GTTS.
A good blog, but that jarred me. I think it's shortsighted, and only effective when you are certain of a monoculture of your target platform. I pass no judgement saying that, 'cause it does work, today, in some spaces, but I want to observe that the future guarantees nothing.
Remember: "This too, shall pass."
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:46 PM Mark Crandall
I did not know that this was how it was done at Microsoft. This is good stuff.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:44 PM Erik
Ugh... reading this makes me queasy.
Some of the principles here are in fact good design tactics and methodologies, but #10, #12, and #13 make me want to retch.
Design time is the most important part of the development cycle! You should be able to model all major aspects of the product you are creating ON PAPER before implementing a single line of production code. If this is done, the code practically writes itself...
Portability is for canoes? Excuse me? That works great if you are arrogant enough to think that the whole world uses Microsoft Windows for everything. People use Windows when it doesn't matter whether it actually works. I'm sorry, but my mission critical code needs to run on UNIX, which means writing portable code....
Great software, my ass. A translation of this is: Snow the customer, they don't really know what they want anyway so if we can make them think our stuff is good enough, we're GOLDEN...
Erik
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:47 PM Eric
As far as Turbo Pascal goes, I used that software, and it was great. What these "21" illustrate are the rules for reliably delivering software in a team environment.
Any individual is capable of any single great thing, but was every software application that Philippe wrote that much of a success? Could he have maintained that software all by himself?
Philippe started a software "venture" that turned into something much greater. I totally agree with your comments about linux and PERL in regards to this.
Do you think Linus Torvalds could maintain linux all by himself? No, he has the kernel team, and they have thier own rules (perhaps unwritten) for software development.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:48 PM Peter
[Quote]I think the "sour apples" on this message board probably haven't been involved in real software development. It can be such a challenge to get a team on the right track to have predictable results in the end. [/quote]
I have been developing software for 10+ years. I have been working with development on the Windows Platform for a greater portion of the software. That is why I cannot fathom how some of the bugs / lack of features go on for that long because I know that if i had any part of that project i would work day in and day out until every bug that I ran into or every bug that had been reported was fixed.
I mean how many people want to hear back from every single email they send out, "Hey your Footer message does not wrap in my email viewer". Being a software developer, I could never ship a product knowing a bug like this was around.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:47 PM Brian
Great work Jim. These aren't just Microsoft specific things. Anyone that has ACTUALLY worked on developing and shipping a commerical product (not an internal job or open source/casual project, though they can be approached the same way) will know that all of your points are the foundation of sound engineering. It's not rocked science, it's just a matter of understanding and getting all these things happening.
Cheers
Brian
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:47 PM gbassett
I have always understood the triangle to be Cost-Schedule-Performance. I find it interesting that here, performance is replaced with features.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:52 PM vlion
Interesting.
Most agree with what I suspect about commercial software development.
I would suggest that a well-designed piece of software is somethat can be put on multiple similar platforms without colassal amounts of effort.
I would also suggest that the shining peak of a piece of software is that it does its job, with zero bugs.
Regardless of the tolerance of a project to bugs, the point of QA should be to have zero bugs, whether this can be accomplished or not.
This way there is a constant striving for perfect software.
I believe that in a team enviroment, the "guy in a room" is a failure.
:)
Facinating writeup.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:50 PM Re: guy in a room
re: Guy in a room from Tom (we're talking large teams)
Tom, the point is: in a large team, having a 'guy in a room' is a liability. How can you predict if the person is going to succeed? Maybe he does, maybe he doesn't - but banking the success of a team of 50 or 100 other engineers and ultimately the financial future of your company on a 'guy in a room' is a risk not worth taking in a large company.
This has more to do with the stage a company is in. In startup mode, it's AOK to be scrappy and risky. But once you have a large estabilished base of customers, scrappy and risky isn't smart business. If you slip, your sales team might not make their quarterly numbers, or worse, you open a gap for a competitor to take away future sales or even your market segment. Sadly, big business is about predictable quarterly numbers to keep wall street and the shareholders happy. In the end, a man in a room in the dark for weeks on end isn't a predictable bet.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 4:58 PM Chris Smith
The articile was well written and if all software projects were ran like that I am sure the programming industry would have much more respect than it does now. But instead of trying to unify programming people into creating a set of 'best practices' we, refering to the /. crowd, simply bash on the man because he is from Microsoft. Good ideas are good ideas are good ideas. I for one will be taking these 21 rules to heart.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:00 PM mjchang
Your first point 'Don’t know what you don’t know' should be 'Always acknowledge that you (and everyone else) don't know'. To me the original sounds too much like the 4 phases of knowledge:
1. You don't know what you don't know.
When you were 5 you didn't know about calculus.
2. You know that you don't know.
At some point you become aware of calculus.
3. You know that you know.
You've learn calculus and you are applying it.
4. You don't know that you know.
You have done so much of it that its a part of your foundation - i.e. Astrophysicist.
# re: 21 6/25/2004 4:59 PM jason mhz
How will this method evolve in the light of the Open-Source myriad developer bazaar model?
Can closed source survive? Is a small closed source development team analagous to a "Guy In The Room" compared with open source development models.
Fair enough you can release software your way but can you keep up with it post release? i.e. fixing it - there seems to be a exploit to patch lag which is leaving many of Microsoft's customers vunerable and is seemingly bad for Microsoft's market share. How can closed source non-free developers encourage the participation necessary to compete/ survive?
No spin, genuine answers only.
Release the source - let windows fork.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:00 PM Computing
>Demand multi-platform support from your >system software vendor, then build your >product on the absolute fewest number of >platforms possible.
If your going to do that, make sure the public knows how your product works, so they an adapt to it too.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:05 PM poster
" " MS has absolutely NO "fantastic" products."
" Right, because you're the one rolling in billions?"
Making money does not prove good products. If their products weren't buggy, susceptible to so many virii (see buggy), bloated, and overpriced, then they would be much closer to "fantastic"...
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:04 PM Mr.H
Great products are great because they satisfy the needs of their core audience, period. No piece of software will every satisfy every need of every person using it (unless it's utterly trivial). The thing that I think /. folks need to keep in mind is that they are NOT part of the core audience for most MS products.
Take a second to consider Excel from the perspective of a non-programmer... pretend that you're an AP clerk tracking payments to vendors, for instance. Excel is fast, it's accurate, it makes tracking payments simple, there's little or no mystery about what's going to happen next... Excel is an insanely great product from that perspective.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:07 PM praxis22
The link may be useful in dealing with this:
http://www.microsoft.com/security/incident/download_ject.mspx
Because currently very little else is, and that includes Microsoft's 20,000 programmers. Still, at least they've appointed somebody to evangelise about how great IE will be once they start working on it again.
I do use XP btw, but IE has to ask to get out to the 'net, and I wouldn't trust outlook anywhere near my home network.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:09 PM Tom Hudson
Reply to post:
poster wrote:
re: Guy in a room from Tom (we're talking large teams)
Tom, the point is: in a large team, having a 'guy in a room' is a liability. How can you predict if the person is going to succeed? Maybe he does, maybe he doesn't - but banking the success of a team of 50 or 100 other engineers and ultimately the financial future of your company on a 'guy in a room' is a risk not worth taking in a large company.
---- end snip ----
Actually, Borland International was famous during their heyday for allowing this. There'd be a few guys who would let things slip, but it was always acknowledged that they were able, as the deadline approached, to just "lock themselves in a room with beer and pizza" and bang out the code in a week.
It's when Kahn left and the corporate culture changed that they lost their dominant position in the market.
It's more profitable to separate the critical workers from the code drones in many cases - otherwise, you end up with the lowest common denominator.
This applies to many fields, not just for coding. It also applies to marketing and sales, for example, where you don't want your star performers to be dragged down by the dreebs because it will cut into your bottom line really quickly.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:07 PM Jemanu
re: Tom Hudson
This beware of a guy in a room thing I belive is talking in context of a team. Beware of the guys that can drag down a team because you never know where they are. If a team is of one person then the guy in a room doesn't really matter, but if a team of 20 or so programmers has a guy in a room that demands to be left alone and doesn't give progress reports, the team could be in trouble.
I see a lot of remarks here picking apart this listing because they don't like microsoft products, or are not thinking inline with what that list is talking about. It is talking about the managment side of large programming jobs. How to help keep on track and to keep moving. Not about microsoft word or windows os, it is just managment points.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:09 PM gwai
#12: Portability is for Canoes
"... Demand multi-platform support from your system software vendor, ..."
What system vendor would this be? Who else writes system level software for the MS platform other than MS?
"then build your product on the absolute fewest number of platforms possible."
I agree that portability is a major PAIN, whether writing a reasonably complicated html document, or writing a program that has to handle different versions of an api. Both are examples of different types of portability - another word for adaptability (or genericitiousitatiotalitousnessity ?!?! get me a dictionary)
But I ask, why is Microsoft pushing this kind of advice? Surely Microsoft wouldn't hire somebody who has absolutely no programming experience with the MSAPI, surely all MS developers know that the windows api is static (I don't mean that in a bad way) and stable in terms of its interface and the hardware combinations are reasonably well encapsulated.
The MS platform is unchanging, and ms developers know this, and write code to specific to the platform by nature of being - MS developers. So why is Microsoft putting this message across?
I am highly sceptical of the motive, to me, this message means: Welcome to the MS island, it is a big island, with lots to do and play with, and lots of room to explore. But you are not leaving this island. Ever. And by stepping aboard, you are helping to increase us, and isolate us, and yourself from other islands, which is good for us.
I don't fault the author of this particular page, but #12 triggers something in my imagination, that makes me wonder is this the culture that MS management is trying to create?
My insight says nothing about the rest of the article, well done for taking the time to write this for others.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:11 PM pascal
This is all good advice, but sorely lacking in concrete examples, and written in a ridiculously ironclad style that leaves no room for doubt or criticism. It would be a lot more interesting, and persuasive IMHO, if it allowed for exceptions, if only to prove the rules.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:14 PM LWATCDR
"The Slashdot crowd might disagree, but I would say that this approach has turned out fantastic products for MS."
It has also produced some real stinkers.
DriveSpace?
Bob?
WindowsME
What did they call embeded windows way back before CE? Windows for Devices or some such thing?
Windows for Pen computeing I think was another bomb.
How many holes have shown up in Outlook and IIS?
I understand that Microsoft really never intended the Windows 9x Codebase to be humg out on the internet for everybody and there dog to have a shot at but Outlook, IIS, and the NT codebase have all caused way to many issues.
IE not following W3C standards?
Sure Microsoft has made some good programs. Word, Powerpoint, Age of Empires are all good programs but nothing magical.
Windows 2000 and WindowsXP where pretty good OSs.
The products that Microsoft really did a great job on should be most proud has to be Excel. It was such a huge leap in Spreadsheets. Of course it was writen for the Macintosh :)
Trust me I have plenty of reasons to be really ticked off at Microsoft. Anyone that has had to use MFC does. But I would never say they have never turned out a good product.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:14 PM kevin schmidt
Great post Dave, I really enjoyed your perspective on development and the great idea's shared within that perspective. Keep up the great posts.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:15 PM Thomas James
An interesting read, but yet again cannot be applied to every team environement. And the guy that said it only applies to commercial should re-evaluate his thinking. But that said it is still very microsoft to believe that portability is not important. I agree that portability requires more time and effort but if your writing a piece of software like office wouldnt you want the broadest market? (windows and unix and apple, yes i know office is available for apple)
Zero defects should mean zero defects and a bug is a defect.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:16 PM Bill F.
Wow, the Slashdot loonies are out.
And they wonder why Linux never goes anyplace fast...
Smart move guys.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:15 PM Server :P
The only thing I use windows for is to play games on it. Other than that I use linux. But in comment to the steps. I agree with most of them being a software programmer myself its just that the software put out has already been made 30 times. Not meaning that in a bad way.
I also believe that you should work more with the performance than the features part of the software. I'd rather have something that worked really well than something with a whole bunch of unusable features.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:18 PM Morris
12. Portability is for canoes.
does this apply to file formats as well?
i.e. make sure others can read the files your customers author.
or 12. Lock your customers data in a canoe and watch it float downstream never touching other shores.
# I am the guy in a room 6/25/2004 5:16 PM guy-in-a-room
Fear me. Hate me. You will be overthrown by me.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:19 PM Thomas James
"Wow, the Slashdot loonies are out."
Troll.
Why bother posting at all?
---------
that said,
I agree design is very very important. Even for a small project. Knowing where your going AND how to get there is invaluable.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:19 PM Joe
"Portability is for canoes" is really going to bite Microsoft as the 64-bit conversion proceeds. If all of your code assumes little-endian ILP32, an LP64 world presents all kinds of hazards.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:18 PM Ming Jack Po
That really is an amazing guide to building a team for any project, not just a software project. I think the /. crowd on this board needs to stop the bandwagoning. What is most amusing however, is that most brilliant programmers seem to be the type to be
"the guy in the room"
because it is far easier to work alone than having to explain yourself every step of the way.
My question is with Microsoft hiring so heavily from that group of prodigies (from Harvard / MIT / Caltech /etc)... is Microsoft actually successful in turning team into team players? and if so, how?
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:24 PM Henry Burgess
My rule number 1 is: there is no substitute for really knowing how things work. When developing system software I made a point of understanding the system down to a low level. So for kernel work I made a point of having the schematics and chip descriptions as well as access to the vendor’s hardware architect and test managers. In my early days at Microsoft I made a substantial hardware change, implemented it and gave the results back to the manufacture. When designing the early CD-ROM file system I made a point of understanding the physical device very carefully. To prove to myself that I had this cold, I held a one-on-one with Bill Gates so that he too could “drill down”.
At Microsoft I was always surprised how many managers did not take the time to read every line of code in the product. When working in Office and on the Tablet PC this was not possible. But it was possible to read every line in my group’s contribution as well as every change “checked in”; as well as satisfy myself that the managers of components on which I depended were doing a quality job.
Sometimes a project was too large or my time spread too thinly to drill down as far as I would have liked. But it was always possible to hold a one-on-one with a developer and determine quickly if they had done so.
By the same token it is critical for the CEO to occasionally drill down to the lowest levels. Bill and to a lesser degree Steve do this. Andy Grove did it, as did Steve Jobs. But I bet that you can now find a number of VPs at Microsoft that have no clue how many critical components work.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:23 PM Tom Hudson
Here's an interesting take on the "guy in the room" from one of the other posters on /.
--- quote ---
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.
--
Mood: livid -v
I look for things. Things that make me go.
--- end quote ---
And, for Bill F., who wrote:
Wow, the Slashdot loonies are out.
And they wonder why Linux never goes anyplace fast...
Smart move guys.
--- end quote ---
Interesting in light of the latest Windows/Explore exploits that hit a bank and other large sites:
http://zdnet.com.com/2100-1105_2-5247187.html?tag=zdfd.newsfeed
The recommended cures: Don't use Internet Exploder. Stay away from sites that use Internet Information Sucker. Now, remember, according to the article, we shouldn't consider these "bugs" as defects.
Microsofts' marketing and development philosophy seems to be "throw enough shit at the s/wall/public/, and some of it will s/stick/sell/".
Microsoft, and its' software, stopped being "cool" sometime after WFW311 and DOS 5.0.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:26 PM Eric
"Portability is for canoes." -- is exactly on target.
Non requirements-driven portability, from my experience, has been a waste of resources. I've been on project teams where some individual (who somehow exerted influence) has insisted that our database access code be limited to "plain ODBC" capable calls, "in case our client decides to switch databases!".
Databases are a key piece of infrastructure that are purchased based on features and performance. So, for the "sake of portability", we had to commoditize a strategic piece of infrastructure in order to be "portable" -- NOT at the client's request!
Portability for portability's sake leads to comprimised performance and unnecessary weeks added to the development schedule.
I believe the author's point of "Portability is for canoes" is a good one. Granted, if your audience NEEDS portability, put it in there [the CLIENT drives the development afterall...], but on the off chance that someone MIGHT switch all of there servers to running Open VMS in the future, I don't think that we should build this portability "just in case". In a cost-equivalent world[both performance cost and $$$ cost], of course, be as portable as possible, but software is already expensive enough without having to open up your audience.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:27 PM eston
" MS has absolutely NO "fantastic" products."
Right, because you're the one rolling in billions? Greatness is certainly subjective, but theirs has a lot more tangible evidence.
^ Agreed entirely. You can be full of all the anti-Microsoft zeal that you want but in the end you have to look at who has the market share. Sure, some marketing-filled lobbying and bullying advanced the cause in some areas but that didn't put Microsoft and its products where they are today.
As for whoever talked about the developer of Turbo Pascal, I have to say that I don't think that's the point of the "beware of a guy in a room" philosophy that they're stressing in this article. They aren't slamming the guys like me who lock themselves away to code solo on our own projects where WE are the sole developers, but rather the people that lock themselves away when they're part of a development team. When you have a team working on a project it is ESSENTIAL that your team communicates as to make sure you don't have conflicting 'features'. If I'm working on a team to develop a networked videoconferencing system, I have to communicate with those guys constantly, show them the things I've written (even if that's only one or two simple functions), and then ask them how far they are and what they've done on their DLLs, and what they have for me as a UI developer, etc.
Don't get me wrong though, I'm an independent developer too. I'm working on some open source projects and have been writing (and selling) my own products for years. Since I AM the development team in this circumstance, who cares if I get antisocial? I can communicate with myself since I'm in charge of everything. I agree wholeheartedly with the guy in a room developers being "anathema to shipping great software on time" in a TEAM environment which is what they're talking about here.
"I find it interesting that here, performance is replaced with features."
Look at a track-based Ferrari Enzo and something like a Rolls-Royce. The Enzo has no radio, I don't even know if it has air conditioning. It's built for nothing but performance. For the same cost (well, sort of) you can have a Rolls-Royce Phantom, but that Phantom's not going to ride on rails through hairpins and you'd be laughed off the track at your hobbyist track day.
The thing is for the same development costs: you can pack your software with useful features that customers will love and use, or you can work on the optimisation of the code to make it as streamlined as possible. You'll follow a different mantra based upon who's buying what. The main user of corporate products is carrying a small Centrino notebook that will run Office or other feature-packed products efficiently enough. If you're building a time-critical database server obviously you're going to want to spend more time optimising it to query faster, since that's more important. I think, though, for most commercial applications, you know the hardware is manageably fast, so might as well get more features in there. It gives people more to work with and looks better in the marketing department. If you aren't having good relations with the marketing department, you're not going to make another piece of software again. Now, this doesn't mean you should throw performance out the window, but if the mainstream user's hardware can handle it, you'll be alright.
The reason that open-source projects don't follow this mantra is because the timetables are a bit more lax. It's a hobbyist venture under nearly all of the software circumstances. They can tinker around with it at three in the morning and be like "Hey, this way of doing it's quicker." In a corporate environment you don't always have that liberty. You have a deadline and you have someone expecting a product.
That is why I cannot fathom how some of the bugs / lack of features go on for that long because I know that if i had any part of that project i would work day in and day out until every bug that I ran into or every bug that had been reported was fixed.
I mean how many people want to hear back from every single email they send out, 'Hey your Footer message does not wrap in my email viewer'. Being a software developer, I could never ship a product knowing a bug like this was around."
You'd think QA would catch it but sometimes things slip. I do agree that Microsoft is a little slow to fix bugs because I think they're too worried about getting another product out there. They need more labor that sits around and fixes bugs. :) Time is the most scarce resource on the planet, and if you have been told to get another project done by said deadline, you may have to put off those bugs for later. That's not your choice as a developer half of the time; it's the manager's choice. The business side of things can hamper your passion sometimes. Most of the time.
Oh, and if any of those MS developers are really so unhappy about working at Microsoft, tell them I'll take their job. It really beats doing some of the things I've been doing lately.
Overall I like the article, and I'm forwarding it to my development team, and using some of these ideas in my solo project development as well.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:29 PM groomed
This is a good article, but it does remind one slightly of the Eskimo who came to Chicago and proceeded to lecture the citizens on the importance of cutting the ice into cubes of exactly such-and-such dimensions, before starting to build the igloo.
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:31 PM Eric
Funny point you mention...
"And, for Bill F., who wrote:
Wow, the Slashdot loonies are out.
And they wonder why Linux never goes anyplace fast...
Smart move guys. "
I always here about the "linux threat is just around the corner"...how many corners have we been around? I think this leads to the whole "spend your credibility" argument of point #7...
7. Never trade a bad date for an equally bad date
...still waiting for that Linux desktop!
# re: 21 Rules of Thumb – How Microsoft develops its Software 6/25/2004 5:33 PM Steve
"Anyone that has ACTUALLY worked on developing and shipping a commerical product (not an internal job or open source/casual project, though they can be approached the same way) will know that all of your points are the foundation of sound engineering."
Just a minor nitpick. Open source can very well be commercial, and is often times not a casual project. Look at Linux, Apache, Sendmail, OpenOffice, Mozilla etc... These are all major open source projects that are all very stable, in many cases more so then any commercially available product. Take a look at the Netcraft stats... every single site in there for the longest uptimes is running some open source OS, Linux, or a BSD, and they are typically running an opensource web server, i.e. Apache. Grouping Open Source software with "casual projects", is just ridiculous. The open source method has been tried and proven and thats why so much migration is going on. I'm not saying that MS can't produce a good product, I admin an exchange server which is nice, but we are migrating to OS for many other reasons. The open source way produces some of the best quality code in the world. The kind of code that can't even be compared to in the proprietary world. For example, IE versus Mozilla/Firefox, hands down IE loses. Same thing with MS Office vs. OOo, whats up with MSO and lack of support for formats? Even public formats like pdf that are supported natively in OOo, need to be payed for as a 3rd party plugin for MSO. At least thats how it was last I checked. This post isn't a troll, it just needed to be cleared up. All the MS Fanboys have been fed so much fud, sometimes facts are distorted. Just a few years ago, I was one of th