21 Rules of Thumb – How Microsoft develops its Software

Artykuł
06/24/2004

I will be presenting a session at TechEd in Amsterdam next week on the subject of software development – “21 Rules of Thumb – How Microsoft develops its Software”. 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”.

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 UK back then, and have delivered MSF training courses and seminars to customers many times over the years.

All the information you need on MSF can be found at https://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 San Diego, works with MSF.

Here is Jim's original article:

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.

Comments

Anonymous
June 24, 2004
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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
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
Anonymous
June 25, 2004
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>
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
"this approach has turned out fantastic products for MS."

MS has absolutely NO "fantastic" products.
Anonymous
June 25, 2004
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
Anonymous
June 25, 2004
Great philosophy. So why is it that MS never bothered to implement it again?
Anonymous
June 25, 2004
" 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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
I've always just followed one rule all along: K.I.S.S.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
ubercodemonkey - Dumping core with the best of 'em... » “The project”
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
Re: 5 ... Zero defects does not mean that the product does not have bugs, ...

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.


Re: 6. Beware of a guy in a room.

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

The article is self-serving and unrealistic, to say the least.

Overall,
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
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?
Anonymous
June 25, 2004
"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."
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
I did not know that this was how it was done at Microsoft. This is good stuff.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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
Anonymous
June 25, 2004
I have always understood the triangle to be Cost-Schedule-Performance. I find it interesting that here, performance is replaced with features.
Anonymous
June 25, 2004
[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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
>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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
" " 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"...
Anonymous
June 25, 2004
In Principio » 21 Rules of Thumb – How Microsoft develops its Software
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
#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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Great post Dave, I really enjoyed your perspective on development and the great idea's shared within that perspective. Keep up the great posts.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Fear me. Hate me. You will be overthrown by me.
Anonymous
June 25, 2004

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.

Anonymous
June 25, 2004
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?
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
"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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
"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.
Anonymous
June 25, 2004
" 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.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
"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 those fanboys being fed.
-Steve
Anonymous
June 25, 2004
I think the whole "guy in a room" scenario relates to the guy that says "I'll be done in 3 weeks", and you never hear from him again, and pray that he delivers.

He may be brilliant, but as the Open Source world is eager to remind everyone, more eyes make better code.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Here, we don't think of it as a triangle with
Cost Resources Time but rather as a relationship

Features x Quality : Resources x Time

And you choose any 3..
Anonymous
June 25, 2004
""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. "

For good or ill, Win64 isn't an LP64 world. In Win64, only pointers are 64-bit. For a 64-bit integer you've got to look at a non-standard data type (in C++ or C90) such as __int64; if you have C99 then long long will be 64-bit too.
Anonymous
June 25, 2004
IMHO, there are typically three different types of people involved in bringing something to market. Understanding that these are different people with VASTLY different personality types is critical. They are:

1. The software development manager. In many cases this person can't code but is someone who should be able to speak to coders and customers alike.

2. The coder. Let's face it, some of the best coders are unable to actually hold conversations with most people.

3. The customer. These people are, let's face it, NEVER going to take the time to read help screens or "man" pages for software, whether there's really a bug or missing feature or not.

The trick in this is getting GENUINE customer needs and bug fixes to the coders in such fashion that stuff gets done/fixed. I once heard it said that (to paraphrase), "You can lead a programmer to water, but you can't make him drink malt liquor."

Huh? What does that mean?! It means if you're seeing water, but the coder is seeing malt liquor, you are not going to get results. Take the time to both (a) listen to what their objections are AND (b) rationally present your business case to them, and you'll make much more headway.

End lesson: good programming managers are priceless. :-)
Anonymous
June 25, 2004
Eric wrote:
...still waiting for that Linux desktop!

It's here :-)

SuSE 9.1 Professional w. KDE 3.2. Novell bought it at the right time.

Easy to install.
Easy to configure.
Fast.
No viruses.
So ... why not try it?
Anonymous
June 25, 2004
If it were here...this would not be a Microsoft world we are living in. Sorry.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Visual Studio .NET rocks. amazing "piece" of code. =]
Anonymous
June 25, 2004
Do one thing and do it well... like launch Windows 98 in front of 50,000 people and cause a blue screen of death.
Anonymous
June 25, 2004
A very interesting and informative read.

I was rather aghast, though, to come across:

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

I'm sorry, in my book, this just doesn't wash. I agree that building cross-platform software is more work, however it is absurd to claim that it is "beyond the reach of most development organizations". How is it that there is so much cross-plaftorm software out there that is open source, freeware, shareware, or from small development labs? If these small, informal developer teams can manage it, shouldn't a large mature development lab be able to manage it too? I think this is more an issue of priorities. For Microsoft, as well as many other organizations, there is no need, the intention is to extend the monopoly, or to be content to deliver only to the largest user base. For other developers who are tired of catering to a rather ruthless corporation that tries to squeeze every last dollar out of their customers, cross-platform support is a priority.

If I sound bitter, it is because I am. I believe that choice is in the long-term best interests of the general population, and I don't like hearing myopic statements like the above quote.
Anonymous
June 25, 2004
Creating quality software is hard work. I have been struggling at it for 17 years. There are no exceptions to the rule; failure comes more often than success.

Kudos, to any person or company that does manage to put out a good product.

Any person who thinks that Microsoft has no great products lacks experience.

And any person who thinks Linux isn't great hasn't spent much time with it.

Both sides produce amazing stuff and garbage.
Actually I think both sides produce more garbage than amazing stuff.

Software development is in its infancy. In three decades we're going to look back and laugh at how poor software was altogether.

What matters is continuous improvement.
Anonymous
June 25, 2004
pity the earnest & talented MS coders & managers
MS success is built on a foundation of...
[1]years of expert bullying of OEMs to generate a monopoly
[2]years of relying on the above to replace "MS code v1" with "MS code v2" to avoid having to address maintaince of "MS code v1"

NOT excellent products

when you have inherited a near monopoly you only need to create sw that keeps 90% happy 90% of the time
more than that makes no economic sense
its the same as burning shares
i've coded with MS tools for years and every problem i've ever seen stems from their culture of "replace and let wither" rather than "maintain and improve"
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004

Someone always thinks they know how to do it better than you.

Ignore them. Chances are they never worked on anything other than an open-ended opensource project. Timelines and design are meaningless to them; no one dictates what the product should look like nor at which date all its planned features will be implemented. Shipment for them is throwing source code into a tarball and hoping that it will compile on everyone's machine that happens to download it.

Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
"12. Portability is for canoes."

Do you not realize how stupid/short sited this is in a rapidly changing corporate environment ?!?
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004

How does the case of IE relate to rules #1 and #13?

For instance, I don't think that MS even knew what they did not know about security. On the other hand, if MS decided to remain ignorant about the security flaws, then I don't see a distinction between pretending to know something and admitting you don't know something and then choosing to remain clueless about what you don't know.

Perhaps I mis-read rule 13. The first subpart only says that it will appeal to your customer's sense of security. Sense of security in what sense? That the buyer made the right choice of software? Or actual system security?

Or perhaps MS feels that security is for fastening canoes to your car.

I see these as good rules for building software with reasonable predictibility of delivery dates. I see nothing in these rules that encourages great software. The ``Great Software'' rules, 13-20, seem contrived rather than learned through experience.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Better leave this article to Microsoft employees and make revenue out of their buggy products.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
I think the sections on "Theme" could use more exposition. I came away from reading those wondering what you meant by "Theme" and feeling it was sort of a wishy-washy expression of purpose. Other than that, I think this has good advice, particularly the beginning sections. Seems like a crib from McConnell, though.
Anonymous
June 25, 2004
"the complexity of multi-platform support is beyond the reach of most development organizations"

Is it a joke ? UNIX and most Real Time OS es are multi-platform for thirty years. Most of the software upon which the Internet is build is multi-platform (Bind, Apache, ...), most scientific software is multi-platform, almost all open source software is multi-platform. Do you mean that what is easy for almost everybody in the IT field is "beyond the reach" of MS ?
Anonymous
June 25, 2004
I find it disturbing that Microsoft comes up with these derived processes, doesn't give any credit to the primary sources, such as the Software Engineering Institute's Capability Maturity Model, and pretends that it is all generated first-hand through their vast reservoir of experience.
Anonymous
June 25, 2004
Now, how to put this in a book from MS Press ... we must bloat it up by a factor of 100 first. We can do it !!
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The rules are actually pretty good. Well, except for number 12, which goes against my rule-of-thumb:

"A truly successful/excellent program/system/piece of code will be used in ways, and in places, you never even dreamed of."

Given the number of excellent software development books coming out of MS experiences (Code Complete, Debugging the Development Process, Rapid Development, etc.), working with the company must be the ultimate school of hard knocks.
Anonymous
June 25, 2004
Without question, some of these rules are good for corperate teams. The sad reality of working as a developer for a corperation is that you seldom get to engage in Programmer Best Practice, instead being stuck with Industry Best practice.

That being said, there are still some weak points. The hotly contested "Portability is for canoes" is a good example. Portability shouldn't be a religion, but it tends to be easier to port well-made software than poorly made software.

The better your software is under the hood, the easier it will be to port.

Part of the job of software engineers is to sufficiently abstract the problem so that they can work with the problem in its own domain. Once you can solve the problem, you can worry about working with the rest of the world. Thus, all your difficult stuff is separate from the drudgery which connects it with everything else.

This also helps with "Test First" development, if you choose to go that route. Isolation of outside inputs is a key part of thorough tests.

As someone who develops software for a company, I approve of many of David's rules. I also think that sometimes, Rules Are Made To Be Broken. The "Guy in a Room", for example, may be the only way you can get this program to ship on time, and it may be totally necessary to do that.

Where I work, we have "Star" programmers. They go in a room, 2 weeks later the come out with finished software. Everything thinks they're amazing, because they don't have all the infrastructure that other, less productive (and larger) teams have. However, it's precisely because of this lack of tiresome infrastructure that they can accomplish as much as they did.

Understanding when to break these rules should be rule #22.
Anonymous
June 25, 2004
We have all learned these principles in our college classes. They all sound good and resonate with us as what we should do. But the real question is, do they result in good software delivered on time, with good quality?

In order to create a list of rules to deliver good quality software on time, someone would need to have experience with or interview someone that has achieved those results.

Microsoft does not release quality products on schedule. They habitually slip their products by years and release their products way before they have been quality verified.

They do indeed have some quality products, but they are a long time coming and they usually are preceded by many versions of inferior quality first.

This list is similar to the business guru books full of the latest buzz rules. And then there is Peter Drucker, who actually studies the REAL successes and writes what THEY do. Those are the REAL rules.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Yeah there are grammer and spelling errors in my post.

Feel free to attack it because of the grammer/spelling as that proves I can't communicate, or whatever.
Anonymous
June 25, 2004
You know, I think if this article hadn't said "Microsoft" at the top of it, the majority of detractors would have had very different opinions.

I passed it out to our dev team and they agreed with the points almost entirely. Of course, I did a big Find and Replace first, replacing "Microsoft" with "Sun Microsystems."

As for the negative comments about "portability being for canoes" -- isn't this the whole POINT to Microsoft development, to create an ad-hoc platform that does what people need to do and not just support legacy operating systems forever? Complain all you like -- so far, this philosophy has worked very well from pretty much every standpoint, and if you want to argue with results you can talk to Mr. Futility.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Microsoft ***** *** ***** ****** *****!

(censorship mine, fill in your own)

may I offer

22) when you sell a toolkit, compiler, IDE, or whatever, make sure its at least a couple revs off of what you use to build your products

23) no matter what, make sure it makes the competitors applications cease to function

...I could go on, but face it, we all know Microsoft ***** *** ***** ****** *****!

I think that sums it up.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
On the topic of "flaws":

- they don't under[stand] the business we are in

In my experience this is usually a communication problem. If there is no clear statement of what business you're in then you get what you paid for.

- they are lazy

Most lazy programmers are that way because they're bored, tired, and/or useless. The first two are solvable by changing their work, the last by changing their employment status.

- they are incredibily concieted, because they know how to [do] whatever and nearly everyone on the planet can't equals they are smarted than everyone else.

Conceit lasts only as long as they never meet anyone who is smarter. Get someone smarter in there to shake them up a bit.

On a side note, having come from outside the U.S. I find this problem more here than elsewhere. Maybe its a cultural thing?

- they can't follow orders
- they won't follow orders
- they rebel at the thought of orders

Orders work really well in the armed forces, where unquestioning obedience is potentially a life and death issue. Most software development is not like that - its a creative endeavour. Get people involved in the decisions, and you don't need orders.

- they know better than the plan

See above.

What worries me about these last 4 is that they scream 'control is more important than creativity'. To wit...

- YEAH! this feature would be cool to add
Anonymous
June 25, 2004
the answer, as always, is: IT DEPENDS. All the things people talk about that make development better all hinge on what the requirements are. The article could be made better if perhaps it outlines the environment that these rules work in.
Anonymous
June 25, 2004
Remember the title here, folks. Shipping great software on time. This implies three things: shipping (meaning "sending to stores," not putting on a website somewhere), great software (meaning not a small utility to perform one task well or an incremental improvement over the previous version, but a completely new and one would hope useful product) and on time (meaning there is a definite deadline).

These are three of the most important things for commercial software. But none of these things really applies to open source development. Open source software doesn't have a date, it takes its time. Open source rolls out features one at a time over a long period; it starts with doing a single thing well and adds things on to that. And finally, open source software does not exist on sold shiny plastic disk that will be used to install it for the next five years.

As a result, Open Source doesn't have to, nor should it attempt, abide by the majority of the rules presented here. If you're able to offer real-time feature slices whenever you like, you don't have to offer software that has acceptable bugs or restrict yourself to a single platform. But you have to realize that, besides operating on a different development platform, you're also appealing to a different class of users. Users who are used to buying software on CD at a store once every two or three years may not be ready for software that does half as much downloaded weekly. And therefore, you can expect resistance from them.

The first time I installed Mozilla, it was slow, plain and incompatible with most plugins and web pages. Now it's fast, feature rich and stable. But if I only had the first experience to go by, I would have to say Mozilla was garbage. If Mozilla had been a Microsoft product, I never would have seen the version that I saw. Instead, I'd have seen a program that was quite compatible and feature rich, but that had bugs in some less common features. The OSS model is better for utilities. The Microsoft model is better for packages. Which is better for you depends entirely on what you want, how much you can pay, and whether you're willing to wait.
Anonymous
June 25, 2004
How Microsoft develops its Software. it doesn't matter. the general public is so gullible they will buy anything.
Anonymous
June 25, 2004
'control is more important than creativity'

Creativity should've taken place back in the planning stages.

Say you're building a house. You're the general contractor responsible for the job. The architect has done their job, as have the lighting designers, feng shui consultants, etc, etc. You have the blueprints in hand.

Do you really want to spend half of each day explaining to the roofing contractor why the bathroom is being plumbed with 3/4" copper?

Not everything can be built by committee.
Anonymous
June 25, 2004
Please use something like QT as an example to follow... not MS.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Shipping great software on time is a difficult but not impossible task.

How come then Microsoft never ships products on time?
Anonymous
June 25, 2004
"A truly successful/excellent program/system/piece of code will be used in ways, and in places, you never even dreamed of."

See IIS, RPC, IE, ADODB/JET

Reusing code only reuses the bugs imho :)
Anonymous
June 25, 2004
Imagine a company (Brand $) that bottled air and sold it all of the world's top companies telling them that this air is 10 times more healthy for you than free air.

Imagine that the world's top companies now made every employee use only this air while they were at work.

Imagine these workers now at home, only using Brand $'s air and making their children use Brand $'s air.

Imagine Brand $'s suddenly becoming the worldwide supplier of air, even though a free source that is just as good as Brand $'s air exists.

If this seems totally ridiculus, then I've gotten my point across. If its stupid for air, it's stupid for software. End of the story, end of argument, its just that simple, but no own that loves Brand $'s air can see how they started using Brand $'s air or why they should use free air.

This world is doomed.
Anonymous
June 25, 2004
What happens when the Slashdot hordes descend on an unsuspecting Microsoft manager's blog?

David got almost ten times more comments in a few hours than in the previous six months.
Anonymous
June 25, 2004
Imagine Brand $'s suddenly becoming the worldwide supplier of air, even though a free source that is just as good as Brand $'s air exists

Too bad the "free air" is not really as good as it touted to be.
Anonymous
June 25, 2004
"... Too bad the "free air" is not really as good as it touted to be..."

I guess MS IIS vs Appache would be a good example of how Brand $ web server is better than the "free air" version -- NOT!
Anonymous
June 25, 2004
Good Job!
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
When VA Linux (Slashdot) links to one of the MSDN or weblogs.asp.net blogs, comments should be turned off. Or, if nothing else, hits with a HTTP_REFERER from Slashdot.org should be automatically redirected to ScatPorn.com.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
OK, more on "portability is for canoes".

Let's look at that link again:

http://www.joelonsoftware.com/articles/APIWar.html

Right now, people who thought "Portability is for Canoes" are having to deal with the cost of non-portability. Microsoft's API's are going through an upheaval, right now, and non-portable code is breaking. More code is breaking than would have broken if Microsoft hadn't insulated people from the changing software environment for so long, and of course Microsoft will no doubt continue to protect their own developers, but out here in the real world we're all in canoes...
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Ortie
Anonymous
June 25, 2004
No wonder windoze is a crappy os
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
This is a useless comment.
Anonymous
June 25, 2004
Apparently most of you missed the author's preface:

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

Which AFAIK means: All the rules may not apply to you, but several of them will, choose wisely.

Works for me.
Anonymous
June 25, 2004
Interesting article. Every time I have to use these horrible CDE based applications in my HP360, I wonder what the state of the art would be without all the available MS applications. Linux is indeed now more usable because we have an example and baseline to look at: Windows.
Anonymous
June 25, 2004
"... IIS vs Apache isn't really a fair comparison. IIS does quite a bit more than Apache does, being an INTERNET server and not merely a WEB server...."

Yes, but can't you assume Appache is running on a *nix platform with all the other "free air" services you want running on it so it, too, is now a INTERNET server as well?

I guess this recent IIS/IE problem is rare?
http://zdnet.com.com/2100-1105_2-5247187.html?tag=zdfd.newsfeed
Anonymous
June 25, 2004
The article would be more convincing if it stops using the phrase "Great Software". The most ironic rule is Rule 20: Establish a shared vision. If only all team members had shared the vision or recommendation of Yaron Y. Goland's on the security of SSDP, we would not have to disable the SSDP service these days.

http://www.goland.org/Tech/upnp_security_flaws.htm
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
I have seen a bunch of people complaining about how MS shouldn't be claiming these rules are there own, how MS doesn't follow them, blah blah blah.

Remember, when you read something on the internet it is not gospel. This guy is writing in a blog about a presentation he is giving on 'rules of thumb'. This is a blog, this isn't an official MS Press Release. This is a guys presentation on 'rules of thumb' not 'official rules for software development per Microsoft Corporate Handbook section 2 part 1 paragraphs 5-23.

Some of this stuff I don't agree with, some of it I agree with, most of it is common sense - once you have experience in shipping a large commercial product.

Everyone needs to remember to just chill out, nothing that is said on the internet is going to cause the world to end. This guy can't come to your house and force you to follow all of his suggestions. There is no cosmic force that can be invoked to turn this guy's 'rules of thumb' in to some immutable force binding all developers for the rest of eternity!
Anonymous
June 25, 2004
Great products -- like Windows ME ???
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
I would put much enphasis on some more points:
- good data structures are esential, a good architecture cannot be achieved without them.
- do not rely solely on external "testing teams" and sooo heavy QA procedures. Make the coders use their own software as soon as possible, they'll be more motivated to produce quality things. Hire vicious testers too :-)
- the great manager should advertise best pratices, good ideas, help anyone in his team to inprove by learning from the others. "Ask your colleage(s) for advice" is very productive in my point of view. Frequently, good ideas surge just because one has had to formulate clearly one's problem to ask for an advice. This can save a huge amount of time. I am not talking of lenghty snoring meetings with dozens of attendees...
- I think there is a learning curve for a team as a whole and that a low turnover is better in the long term.

2 EuroCents too...
Anonymous
June 25, 2004
Very nicely articulated. As someone who's been involved with successful and unsuccessful projects for the DoD in the 80's, Microsoft in in 90's (Exchange, IE 3, 4), and others (current), I agree w/ virtually all your points. It's nice to see attention to QA.
Anonymous
June 25, 2004
"... When VA Linux (Slashdot) links to one of the MSDN or weblogs.asp.net blogs, comments should be turned off. ... HTTP_REFERER from Slashdot.org should be automatically redirected to ScatPorn.com...."

Wouldn't work, I'm running firefox, I block the referer, should I need one however I can use refspoof to roll my own.
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
The comment has been removed
Anonymous
June 25, 2004
Well I guess I'm one of the lucky few as I really only have three customer bases: 1) Product Management/Marketing, 2) Operations and 3) the Billing group; all totaling a little over 300 people. Each group gets to submit their own enhancement requests, which are then prioritized and eventually developed. When I implement something for Product, Operations and Billing complain. When I implement something for Operations, Billing and Product complain, and so on. They are only really happy when they get the enhancements that they have requested. I can only imagine how negative the comments would be if my software went out to the world.

And not all bugs are accidents. Some features can just turn out to cause unanticipated issues/exploits/holes. And sometimes, one man’s feature is another man’s bug. Let me give a recent example. We are currently in the middle of a customer address conversion where a customer’s address may exist in one or both of two tables (an old and a new table). If in the new table, the new address window is displayed. As part of the design, the old address window could be reached (read only of course) by holding down the Alt key while clicking on the Address button. The purpose was to allow a quick way to verify that the address had been correctly converted to the new form. Operations almost immediately reported this as a bug because agents were accidentally accessing the old address window and that it was causing confusion, usually when a customer was on the phone with the agent. Now I must fix this “bug” that was in the original design specs.

And I don’t know how many times we've added features and later found out that an agent was using the new feature in some way that we never imagined. Many times we were pleasantly surprised; a few times we were horrified. But even then the feature was performing 100% up to spec, as designed. But that doesn’t mean we didn’t have to scramble to get a “fix” in to keep someone from “abusing” it. I imagine that many of the MS security holes exposed today existed in the first place because the designers and developers never imagined how clever and malicious today’s “black hats” could be.

I guess what I’m trying to say is that a real developer will relate. Those who complain and hate are just users.
Anonymous
June 26, 2004
Are the slashdot idiots gone? The net thugs probably come here just to bash Microsoft again. Linux has no chance with these idiots, there are only very few developers for Linux, the rest are slashdot idiots who are cheering for those few.
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
Heh, MS and "great" together in one statement is valid only when "money" is mentioned in there also.

They are really sad bunch of copycats - and even the copies are bad. Luckily we have Apple which comes with great ideas and their implementation in software, so Microsoft (and Open Source which copies the copy) can copy them, albeit poorly.

You should thank Steve Jobs, because without his company we would still be in DOS world forever. Not that some computer geeks would mind...

There are very few companies that make their customer feel the computer is there to help them and work for them, not vice versa. MS is not one of them.

Comparing 20.000 MS engineers with perpeatually late and buggy and bloated software whichpeople use because they have to with 100 times smaller team of Apple which produces software which customers enjoy using - how can you state MS is great without some serious mental block?
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
The rule exists in theater too -- "You can have it good, fast, or cheap. Pick any two."
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
The comment has been removed
Anonymous
June 26, 2004
All I see here is some arbitrarily made choices, with most of them having little to do with what the quality of software depends on.

It's a great example of a set of principles that can be given to some pointy-haired boss, and so would be any other set of principles as long as it doesn't involve replacing developers with millions of monkeys on typewriters.

Also I see no reason to believe that any of this is relevant to what Microsoft does -- for example since when it happened that they ever demanded their "system software vendor" to produce anything portable, even if one includes their software made for MacOS, and their disastrous failures with using Bristol software and its likes.
Anonymous
June 26, 2004
The geniuses on this thread seem to be missing a few key details:

* These rules were first published nearly a decade ago.

* Jim McCarthy was not speaking for the entire developer population of Microsoft, who, to the surprise of the clever, do not actually behave like some kind of Borg-like hive brain.

* GNU types were making the same observations about Microsoft twelve years ago, at the dawn of Linux. They were boring then, too.
Anonymous
June 27, 2004
QA, Development and Millions of users

I think these hints are for the case of very large numbers of users, hard to upgrade long lifetime software, and very large projects.

When you ship millions of copies (240 million XPs I read recently) and these copies might be used for 5 to 8 years it seems prudent to have structure in your process and a large QA group.

The number of bugs found grows with usage (and changes) even when software is mature. I think Microsoft must be pretty conservative compared to a website or an application start-up about what they ship on CDs.
Anonymous
June 27, 2004
Dr. Pizza said:
"For good or ill, Win64 isn't an LP64 world. In Win64, only pointers are 64-bit. For a 64-bit integer you've got to look at a non-standard data type (in C++ or C90) such as __int64; if you have C99 then long long will be 64-bit too. "

Actually, for those of us interested in C99 code, there's this little tiny header called stdint.h that defines all sorts of funny things, like, say, int64_t.

And, by the way, long long is 64bit on 32bit platforms, too - maybe you meant long int?
Anonymous
June 28, 2004
The comment has been removed
Anonymous
June 28, 2004
The comment has been removed
Anonymous
June 28, 2004
Mixture of good and bad here, but let's not through the baby out with the bathwater. The "on-time" points are useful and thought provoking, even if I don't quite agree with all of them. The rest however is what happens when the marketing of a product becomes more important than the engineering. Microsoft are great at this. There's no denying it's a great way to bring the bucks in. However, it's not how I personally define "great software".
Anonymous
June 28, 2004
For the last two years most of the imagination and innovation in the world of software development has been coming out of Microsoft. YES MICROSOFT! Java and OSS etc are great but most of their loudest advocates are too busy bashing Microsoft to do any real innovating. Go to the micosoft blogs and you see people thinking hard about how to do things better. Go to the rest of the world and you see mindless MS bashing. look at the coments on the page and tell me it ain't true!
Anonymous
June 28, 2004
"Re: 5 ... Zero defects does not mean that the product does not have bugs, ...

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

No. In this context a "defect" is a bug you've already identified. Saying you have zero defects isn't claiming that there are no bugs, or even that there aren't still lots of bugs - it's merely saying that you've done somnething about all the ones you've found so far.

What's being suggested here is a way of comparing how different parts of the project are progressing. You set a zero defect checkpoint. You have (say) one area where there have been quite a few bugs found, but the developers are managing to stay on top of fixing them, so they have no trouble in hitting the checkpoint. In another, fewer are being found, but the backlog is growing. What's being suggested is that you probably need to look at why the second area is struggling compared to the first, because there's probably a problem there that needs fixing.

FWIW, as a professional tester my own opinion is exactly opposite to the original - I'd be worried about those areas that could make a zero defect checkpoint, and by implication about any process that contained such a checkpoint unless it was entirely open-ended. There always are more bugs in there to be found, and if an area can genuinely get its defect backlog down to zero, that suggests that the test process is failing.
Anonymous
June 28, 2004
The comment has been removed
Anonymous
June 28, 2004
"For the last two years most of the imagination and innovation in the world of software development has been coming out of Microsoft."

I'd like to see some examples of this. I can't think of one, offhand.
Anonymous
June 28, 2004
The comment has been removed
Anonymous
June 28, 2004
Monday, June 28, 2004 6:30 pm. Microsoft makes a lot of money. This is not the same as making good software. Indeed, the two things can be obviously opposed. In terms of software quality, what Microsoft is exceedingly good at is making software that is just good-enough that people keep buying it. Nothing wrong with that, but that's what they do.

On the other hand, I still don't understand why Microsofties don't get strangled every time they utter the word "great" -- particularly the 5,000,000 iterations Gates uses in the typical interview.... I don't think my perfect beautiful software is great; I certainly don't think the puzzling and annoying Word is...

But much obliged for the 21 points; at the least, it saves buying the book....

--jgo
Anonymous
June 29, 2004
The triangle is wrong - there are four variables to software development: resources, features, schedule and QUALITY.
Anonymous
June 29, 2004
Remember, writing a good spec. not only clarifies your ideas; it's far quicker, easier and more cost-effective to rewrite a spec. than to rewrite software -- and the specification itself can be recycled and modified by various depts. (marketing, sales, management, etc.) for their own purposes.

There's a really great article going into more detail
on this at
http://www.joelonsoftware.com/navLinks/fog0000000247.html (scroll down to "Painless Functional Specifications")
Anonymous
June 30, 2004
"The triangle is wrong - there are four variables to software development: resources, features, schedule and QUALITY"

I agree, which is why one of the rules is on Zero Defect milestones - this is where the quality aspect is managed

cheers
Dvaid
Anonymous
June 30, 2004
Having had some time with computers (first one a ZX Spectrum in 1984), first PC in 1995, and having collected a HUGE list of software, I can only say I USED to admire Microsoft, now I just go through learning C to hopefully build something to make people's lives easier with this incredibly restrictive and unintuitive system, Windows32.
I remember the days...
- When Quarterdeck and Qualitas really saved you the conventional memory and made your system really crashproof
- When Helix Software (eaten by Network Associates) and Aldridge software provided fantastic Windows-compatible caches that worked very much faster than VCACHE
- When the system ASKED YOU about your setup, if the numbers were wrong the device didn't work, it was YOUR FAULT, but YOU COULD REASSIGN without HASSLE! I hate plug and play because of the random way it assigns interrupts, it really stops you cold sometimes, and no legacy support means your old MS-DOS games can't be played with sound, don't believe the hype that Dell/HP/whoever branded tells you they are SB-compatible, they are only SB-Compatible IN WINDOWS (which has a HAL anyway, through DirectX)...
- VCACHE is slow, but I have no choice, it seems, new machines cannot run the old utilities. I am hoping M$ will release a MORE CONFIGURABLE programme, it is stupid when the only thing you can adjust is its maximum size and smallest cluster. What about other options like cache strategy: LRU or MRU or Associative? And why no way to configure time before cache flush?

That's about it for the cons. Now for the pros:

But remember Microsoft also unified some stuff:
They gave us OpenMPEG, else we'd still be doing things with the RealMagic cards.
They gave us DirectX, which standardizes output of audio & video, and keeps the SoundBlaster Pro standard alive to this day. (Wow, that's almost 20 years!)

I am currently using Windows '98 just for textfiles, games and internet use.
Everything work/business related goes through Windows 3.11.
I HOPE M$ gets a lesson to improve themselves, or they have some epiphany.
Anonymous
July 01, 2004
Just been to the session. It was really great, I liked this more general overview of pitfalls in software development. It made me think about the Coder to Developer book by Mike Gunderloy, which I'm reading right now. That great book fits a little bit more into my own working practice as a developer. However, as I'm not working in a team really, but on my own most of the time, it's really enlightening for me to see how it is done in the real world :)
Anonymous
July 01, 2004
If these rules ment anything everything would have stopped untin 98 was fixed rather than comming out with even more low quality product.

I have Suse 9.1 pro running on a PII 250 with 256mb. try that with the latest M$.

CWSIV
Anonymous
July 05, 2004
I attended this session at TechEd Europe and as a developer, I recognise a lot of the things mentioned that can go wrong. And I agree with a lot of the points mentioned to prevent going wrong.

I think it is a pitty most comments do not address one of the 21 rules, but Microsoft as a company.
Anonymous
July 06, 2004

Great article! Although, I think one of the best ways to enrapture the user is responding to their feedback instantaneously. While I think this could be very difficult to Microsoft to do, it has worked for other companies, specifically JetBrains.
Anonymous
July 06, 2004
Nice of the intellectuals to attack the source (indirectly MS through one of its employees) rather than the material itself. Would have been nice to see people actually comment on the art (someday science?) of building usable applications, and maybe further the usefulness of the original topic, rather than hop on the anti-MS bandwagon.

I was especially hoping the slash-dotters would chime in and offer their views of critical success factors in building software. Silly me.
Anonymous
July 07, 2004
The comment has been removed
Anonymous
July 11, 2004
thanks for information, the concepts implemented by MS: humiltiy, creativity and persistence can and should be applied in all life's ventures. This also explains why MS is on top and will likely be for a long while.
Anonymous
July 13, 2004
You might be interested in this link to see more of what Jim is thinking these days

www.softwareforyourhead.com
Anonymous
July 14, 2004
It looks like the thread on slashdot is finally dying down

http://developers.slashdot.org/developers/04/06/25/1320252.shtml?tid=109&tid=126&tid=156&tid=187
Anonymous
July 16, 2004
The comment has been removed
Anonymous
July 19, 2004
Ashutosh Nilkanth's Blog » How Microsoft develops its Software
Anonymous
July 28, 2004
The comment has been removed
Anonymous
July 28, 2004
"This is a function of management"

The typical team setup is usually a project "manager" who knows nothing about technology but wants to take control of the project because of the workd "manager" in his/her title. These types of managers should only be delegated to keeping track of project metrics or things such as getting requirements. They should not drive the software project.

The true manager of any software project should be the Software Architect. Bieng architect she would know the technology, tools and the caliber of the team. These factors are what contribute greatly to the success of a software project. Not some theory that got picked up in some graduate business school.

But because of politics (and ego), the MBA types will want to "manage" the software project. As they say we are computer scientists, not computer politicians. When politics enters a software project - might as well consider it a failure.
Anonymous
July 28, 2004
"21 Rules of Thumb for Shipping Great Software on Time"

If I may add a 22nd - automate as much of the software development/coding process as possible. Code generators are a godsend.
Anonymous
September 17, 2004
The comment has been removed
Anonymous
October 20, 2004
my weblog »
Anonymous
February 16, 2005
ChaosElbows »
Anonymous
April 06, 2006
The original article of Jim McCarthy. The book he wrote is &quot;Dynamics of software development&quot;...

Udostępnij za pośrednictwem

21 Rules of Thumb – How Microsoft develops its Software

Comments

Dodatkowe zasoby