21 Rules of Thumb – How Microsoft develops its Software


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 http://www.microsoft.com/msf , including an MSF 3.0 overview white paper, and details of the team and process model, which are at the core of MSF. There is also an update on how Visual Studio 2005 Team System, which we recently unveiled at TechEd in 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 (201)

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

  2. Peter da Silva says:

    Reading this helps me understand many of the frustrating limitations of Microsoft software out in the real world. For example:

    Portability is for canoes (and system software). "Demand multi-platform support from your system software vendor, then build your product on the absolute fewest number of platforms possible."

    Of course, for people outside Microsoft applications like Office and Internet Explorer *are* system software. To Microsoft, they’re the product, and portability is something to be avoided, but to us they’re what we build our own software on: how do *we* build great software for the Microsoft platform if Microsoft’s developers refuse the same support they demand of their software division?

    Remember the chant… "Developers, developers, developers?" We’re all developers, and even if all one of my users is developing is a web page they don’t want to have to fight Microsoft to make it work where *they* need it.

  3. Having been the "Guy In The Room" on more than one project, I can agree with the dangers in that mode of operation. In my case, there were two main contributors to that. The first contributing factor was physical isolation. I’ve been seperated from my team by as much as 3000 miles. Secondly, I’ve been a member of a team where programming in isolation was embraced by the whole group. Nobody wanted to be accountable to anybody else.

    Great programming teams are fun to be on. The quest towards a goal grows people together. The opposite sucks, and makes work drudgery.

  4. Andy O'Meara says:

    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

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

  6. Jim McKeeth says:

    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.

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

  8. duh says:

    "this approach has turned out fantastic products for MS."

    MS has absolutely NO "fantastic" products.

  9. R Clint Ellis says:

    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

  10. unimportant says:

    Great philosophy. So why is it that MS never bothered to implement it again?

  11. Someone says:

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

  12. timecop2 says:

    "dear sir, please stop spewing crap on the internet.

    just because you have a computer and notepad.exe, that doesn’t mean you need to be publishing your tripe for everyone to look at. "

    dear timecop, please stop spewing crap on the internet.

    just because you have a computer and an internet connection, that doesn’t mean you need to be posting your tripe for everyone to look at.

  13. Herses says:

    I’ve always just followed one rule all along: K.I.S.S.

  14. warhammer says:

    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.

  15. Anonymous says:

    ubercodemonkey – Dumping core with the best of ’em… &raquo; &#8220;The project&#8221;

  16. Peter says:

    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.

  17. Eric says:

    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

  18. nrm says:

    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.

  19. Tom Hudson says:

    Re: 5 … Zero defects does not mean that the product does not have bugs, …

    <p>

    I guess this is the opposite side of the coin of "if you can’t fix it, feature it", which gave us the "it’s not a bug, it’s a feature" mentality. A bug is a programming error. Zero defects means zero bugs, zero errors. To even try to argue anything else is to lie.

    <p>

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

    <p>

    So, what about Philippe Khan? 1 guy. 1 motel room. 6 weeks. Result: Turbo Pascal, complete with IDE. Borland then went on to grab 2/3 of the PC compiler market in the 80s with Turbo C.

    <p>Most of the stuff we depend on started with one guy in a room, and an itch to scratch. Linus Torvalds for linux, for example. Larry Wall for perl. A couple of guys in a garage for Apple. php. oython. vim. emacs. sendmail. Heck, even Apache started out as "a patchy server". All the s/good/great/ stuff started out with one or two guys in a room and an idea.

    <p>

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

    <p>

    Overall,

  20. Software Manager says:

    Terrific writeup. You’ve been slashdotted, so expect a huge amount of knee-jerk religous anit-microsoft zeal in the comments (sadly some of Microsoft’s biz/marketing strategy gets reflected poorly on an otherwise great engineering group). From a Silicon Valley engineering manager’s perspective, you’re spot on – thanks for making a cohesive summary.

  21. Frottage says:

    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?

  22. TFOAE says:

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

  23. Erik says:

    Ugh… reading this makes me queasy.

    Some of the principles here are in fact good design tactics and methodologies, but #10, #12, and #13 make me want to retch.

    Design time is the most important part of the development cycle! You should be able to model all major aspects of the product you are creating ON PAPER before implementing a single line of production code. If this is done, the code practically writes itself…

    Portability is for canoes? Excuse me? That works great if you are arrogant enough to think that the whole world uses Microsoft Windows for everything. People use Windows when it doesn’t matter whether it actually works. I’m sorry, but my mission critical code needs to run on UNIX, which means writing portable code….

    Great software, my ass. A translation of this is: Snow the customer, they don’t really know what they want anyway so if we can make them think our stuff is good enough, we’re GOLDEN…

    Erik

  24. Mark Crandall says:

    I did not know that this was how it was done at Microsoft. This is good stuff.

  25. Eric says:

    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.

  26. Brian says:

    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

  27. gbassett says:

    I have always understood the triangle to be Cost-Schedule-Performance. I find it interesting that here, performance is replaced with features.

  28. Peter says:

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

  29. Re: guy in a room says:

    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.

  30. vlion says:

    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.

  31. Chris Smith says:

    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.

  32. jason mhz says:

    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.

  33. mjchang says:

    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.

  34. Computing says:

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

  35. Mr.H says:

    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.

  36. poster says:

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

  37. Anonymous says:

    In Principio &raquo; 21 Rules of Thumb &#8211; How Microsoft develops its Software

  38. praxis22 says:

    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.

  39. Jemanu says:

    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.

  40. Tom Hudson says:

    Reply to post:

    poster wrote:

    re: Guy in a room from Tom (we’re talking large teams)

    Tom, the point is: in a large team, having a ‘guy in a room’ is a liability. How can you predict if the person is going to succeed? Maybe he does, maybe he doesn’t – but banking the success of a team of 50 or 100 other engineers and ultimately the financial future of your company on a ‘guy in a room’ is a risk not worth taking in a large company.

    —- end snip —-

    Actually, Borland International was famous during their heyday for allowing this. There’d be a few guys who would let things slip, but it was always acknowledged that they were able, as the deadline approached, to just "lock themselves in a room with beer and pizza" and bang out the code in a week.

    It’s when Kahn left and the corporate culture changed that they lost their dominant position in the market.

    It’s more profitable to separate the critical workers from the code drones in many cases – otherwise, you end up with the lowest common denominator.

    This applies to many fields, not just for coding. It also applies to marketing and sales, for example, where you don’t want your star performers to be dragged down by the dreebs because it will cut into your bottom line really quickly.

  41. gwai says:

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

  42. pascal says:

    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.

  43. LWATCDR says:

    "The Slashdot crowd might disagree, but I would say that this approach has turned out fantastic products for MS."

    It has also produced some real stinkers.

    DriveSpace?

    Bob?

    WindowsME

    What did they call embeded windows way back before CE? Windows for Devices or some such thing?

    Windows for Pen computeing I think was another bomb.

    How many holes have shown up in Outlook and IIS?

    I understand that Microsoft really never intended the Windows 9x Codebase to be humg out on the internet for everybody and there dog to have a shot at but Outlook, IIS, and the NT codebase have all caused way to many issues.

    IE not following W3C standards?

    Sure Microsoft has made some good programs. Word, Powerpoint, Age of Empires are all good programs but nothing magical.

    Windows 2000 and WindowsXP where pretty good OSs.

    The products that Microsoft really did a great job on should be most proud has to be Excel. It was such a huge leap in Spreadsheets. Of course it was writen for the Macintosh 🙂

    Trust me I have plenty of reasons to be really ticked off at Microsoft. Anyone that has had to use MFC does. But I would never say they have never turned out a good product.

  44. kevin schmidt says:

    Great post Dave, I really enjoyed your perspective on development and the great idea’s shared within that perspective. Keep up the great posts.

  45. Thomas James says:

    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.

  46. Server :P says:

    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.

  47. Bill F. says:

    Wow, the Slashdot loonies are out.

    And they wonder why Linux never goes anyplace fast…

    Smart move guys.

  48. Fear me. Hate me. You will be overthrown by me.

  49. Morris says:

    12. Portability is for canoes.

    does this apply to file formats as well?

    i.e. make sure others can read the files your customers author.

    or 12. Lock your customers data in a canoe and watch it float downstream never touching other shores.

  50. Ming Jack Po says:

    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?

  51. Thomas James says:

    "Wow, the Slashdot loonies are out."

    Troll.

    Why bother posting at all?

    ———

    that said,

    I agree design is very very important. Even for a small project. Knowing where your going AND how to get there is invaluable.

  52. Joe says:

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

  53. Tom Hudson says:

    Here’s an interesting take on the "guy in the room" from one of the other posters on /.

    — quote —

    Beware of a guy in a room.

    I do most of my good dev alone in a room. I even make deadlines! I used to work for someone who used to work at JPL in the 1970s managing software development. One developer would ride his Harley Davidson wearing a cape and goggles and lock himself in a room with the necessary hardware and ask that Twinkies and Coke be left outside the door. They didn’t see him for a week, but the code was good. It was for the Voyager program, so we know it was good.

    There’s a difference between not trusting an ex-frat boy alone in a room and a responsible software developer in a room. Treating everyone on a team the same just breeds discontent. If people work well alone and can be trusted to do so, don’t make them waste their time in meetings.



    Mood: livid -v

    I look for things. Things that make me go.

    — end quote —

    And, for Bill F., who wrote:

    Wow, the Slashdot loonies are out.

    And they wonder why Linux never goes anyplace fast…

    Smart move guys.

    — end quote —

    Interesting in light of the latest Windows/Explore exploits that hit a bank and other large sites:

    http://zdnet.com.com/2100-1105_2-5247187.html?tag=zdfd.newsfeed

    The recommended cures: Don’t use Internet Exploder. Stay away from sites that use Internet Information Sucker. Now, remember, according to the article, we shouldn’t consider these "bugs" as defects.

    Microsofts’ marketing and development philosophy seems to be "throw enough shit at the s/wall/public/, and some of it will s/stick/sell/".

    Microsoft, and its’ software, stopped being "cool" sometime after WFW311 and DOS 5.0.

  54. Henry Burgess says:

    My rule number 1 is: there is no substitute for really knowing how things work. When developing system software I made a point of understanding the system down to a low level. So for kernel work I made a point of having the schematics and chip descriptions as well as access to the vendor’s hardware architect and test managers. In my early days at Microsoft I made a substantial hardware change, implemented it and gave the results back to the manufacture. When designing the early CD-ROM file system I made a point of understanding the physical device very carefully. To prove to myself that I had this cold, I held a one-on-one with Bill Gates so that he too could “drill down”.

    At Microsoft I was always surprised how many managers did not take the time to read every line of code in the product. When working in Office and on the Tablet PC this was not possible. But it was possible to read every line in my group’s contribution as well as every change “checked in”; as well as satisfy myself that the managers of components on which I depended were doing a quality job.

    Sometimes a project was too large or my time spread too thinly to drill down as far as I would have liked. But it was always possible to hold a one-on-one with a developer and determine quickly if they had done so.

    By the same token it is critical for the CEO to occasionally drill down to the lowest levels. Bill and to a lesser degree Steve do this. Andy Grove did it, as did Steve Jobs. But I bet that you can now find a number of VPs at Microsoft that have no clue how many critical components work.

  55. Eric says:

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

  56. eston says:

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

  57. groomed says:

    This is a good article, but it does remind one slightly of the Eskimo who came to Chicago and proceeded to lecture the citizens on the importance of cutting the ice into cubes of exactly such-and-such dimensions, before starting to build the igloo.

  58. Eric says:

    Funny point you mention…

    "And, for Bill F., who wrote:

    Wow, the Slashdot loonies are out.

    And they wonder why Linux never goes anyplace fast…

    Smart move guys. "

    I always here about the "linux threat is just around the corner"…how many corners have we been around? I think this leads to the whole "spend your credibility" argument of point #7…

    7. Never trade a bad date for an equally bad date

    …still waiting for that Linux desktop!

  59. Steve says:

    "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

  60. Eric says:

    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.

  61. Me says:

    Great article. Like them or not, MS has a lot to teach the rest of us about how to write software.

    I get so sick of anything Microsoft being a bad thing. I can barely read Slashdot anymore because it’s not about being a geek…it’s about "Microsoft Sucks" and "Linux Rules".

    Use the best tool for the job…period.

    Thanks for giving us a little bit of insight into how you continue to rule the sofware world.

  62. TriangleMan says:

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

  63. Dr Pizza says:

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

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

  65. Tom Hudson says:

    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?

  66. Eric says:

    If it were here…this would not be a Microsoft world we are living in. Sorry.

  67. usraio clave says:

    About QA: QA people are the hole in the development process. Someone above wrote that "QA is about process." True, but in real life QA is about making sure the software does what it’s supposed to and provides status on what it is doing and not doing.

    QA = quality assurance, which includes quality assessment.

    What that dude is talking about in the comments is "validation," not QA. Validation is a small part of overall QA, and one that most people (including QA people) don’t understand.

    Validation is almost completely worthless. I’ve seen "Validators" sign off on a piece of software that didn’t install, because successful installation wasn’t in the spec. At the same time they passed all the other functions, even though those functions weren’t accessible due to the lack of installation because they couldn’t "prove" they didn’t work.

    Freaking retards.

    So remember, QA is just another way to blow smoke up people behinds. Don’t let them hide behind fancy words. Make sure they do their jobs, and don’t listen to their jargon.

  68. yow says:

    Day after day, alone in a room,

    The guy with the foolish grin is keeping perfectly still.

    But nobody wants to know him,

    They can see that he’s just a fool.

    And he never gives an answer …..

    But the guy in the room,

    Sees the sun going down.

    And the eyes in his head,

    See the world spinning around.

    Well on his way, his head in a cloud,

    The man of a thousand voices, talking perfectly loud.

    But nobody ever hears him,

    Or the sound he appears to make.

    And he never seems to notice …..

    But the guy in the room,

    Sees the sun going down.

    And the eyes in his head,

    See the world spinning around.

    And nobody seems to like him,

    They can tell what he wants to do.

    And he never shows his feelings,

    But the guy in a room,

    Sees the sun going down.

    And the eyes in his head,

    See the world spinning around.

  69. Dr Pizza says:

    "Design time is the most important part of the development cycle! You should be able to model all major aspects of the product you are creating ON PAPER before implementing a single line of production code. If this is done, the code practically writes itself…"

    The only time the code "practically writes itself" is when the code is being written.

    Up-front design is normally wrong. To determine the best way of doing something requires experience in the problem domain, and the only way such experience is gained is by actually trying to solve the problem.

    The right design will evolve organically.

    This does not mean that I would advocate layered hacks or espouse such hacks as "design"; but rather, one should only commit to a particular way of doing things when that way has shown itself to be effective. Code isn’t sacrosanct; if rearranging a piece of code makes the system easier to understand, or easier to change, or more correct, then do it. If this means sacrificing some moron’s idea of the "architecture" of the system, so be it.

  70. Yeah, Right says:

    The only way to get anything done at MSFT these days is to begin ignoring all the meetings at some point, then lock yourself in a room and write the code. MSFT is slowly but surely turns into IBM, you have to make too many people feel good about themselves before they allow you to do the actual work. As a result, there’s not much time left to do it. Management distractions have mushroomed in the past 2-3 years. Working at MSFT isn’t as fun as it used to be. My prediction – as economy recovers Microsoft will lose a BUNCH of really bright people who are tired of all the bullshit written above.

  71. Brendan says:

    I think Microsoft is really good at making software that has the benefits that people want.

    But developers don’t like them, because if you try to do something tricky with these features (like combining them), they usually don’t work.

    This is probably because Microsoft is aiming at a target, which doesn’t include arbitrary combinations of features (nor recursive use and so on).

    Now, I think this is right on for most software users. It’s only developers who really like to be able to combine things, and who admire the orthogonality that enables this to happen. In fact, the inability of developers to accept that perfection isn’t necessary (and that they only need to deliver the key benefits) is something that cripples many developer-run projects.

    So the result? Microsoft makes great products – but developers don’t like them. I personally don’t like Microsoft products on this score, but they are pretty useful if you stay on the surface. So microsoft deserves *some* of its billions.

    Finally, the bad news. Open source is now often developed with a similar philosophy, of delivering the benefit needed – don’t worry if it’s buggy! We’ll deliver early and fix it fast. Linux is lucky, in that it is built atop a fairly well-designed architecture.

  72. yoyo says:

    Visual Studio .NET rocks. amazing "piece" of code. =]

  73. William Nett says:

    Do one thing and do it well… like launch Windows 98 in front of 50,000 people and cause a blue screen of death.

  74. developer says:

    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.

  75. Jon says:

    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.

  76. J.Mac says:

    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"

  77. Pooky says:

    It strikes me that some of these project rules are oriented toward solving problems that could be minimized with architectural choices rather than through drum beating.

    #2 – The QA function might not require the superfriends if you started with Design By Contract and Wrote Your Tests BEFORE You Wrote Your Code.

    #8 – Design should be closed to change and open to extension. If you follow this from the get go slip doesn’t undermine product stability even when it might lead to scope creep under the wrong management.

    #14 – Unity is good. Healthy break points with interfaces you can count on might free the team from some of the NEED for unity.

    #21 – Ship mode?! What a terrifying idea.

  78. C. Smith says:

    As a developer of portable product, I have to agree with point 12. While the development effort for portability is a known quantity, and quite doable (assuming you don’t care much about a rich UI experience), the cost of test is huge and far outweighs the cost of development. If your serious about the quality of your product (and I’m talking retail here, not for internal use), you must include every OS and the versions you want to support as part of your test suite. For a company of less than 500 people, the costs rapidly escalate to unreasonableness. We have wound up supporting Windows and only two flavors of Unix, with 2 or 3 versions each, and our test lab takes up a significant portion of one of our floors.

    It’s not only more work, it can kill your ROI.

  79. Pooky says:

    It strikes me that some of these project rules are oriented toward solving problems that could be minimized with architectural choices rather than through drum beating.

    #2 – The QA function might not require the superfriends if you started with Design By Contract and Wrote Your Tests BEFORE You Wrote Your Code.

    #8 – Design should be closed to change and open to extension. If you follow this from the get go slip doesn’t undermine product stability even when it might lead to scope creep under the wrong management.

    #14 – Unity is good. Healthy break points with interfaces you can count on might free the team from some of the NEED for unity.

    #21 – Ship mode?! What a terrifying idea.

  80. Developer says:

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

  81. praxis22 says:

    Eric,

    Linux on the desktop will never be a consumer choice. It’s too hard to use, and too intimidating, people don’t want to learn to use thier computers all over again. It is for people who find playing with their computers pleasureable, as opposed to people who have something they need to do. Linux is for people who have something to do, but don’t mind spending 6 weeks finding a way to do it on Linux. Becuase they can.

    However, it is beginning to vex Microsoft’s advances into the server market. Where nobody gives a rats ass what the desktop looks like provided it stays up 24/7 and degrades gracefully under pressure. Which is something any form of UNIX is really good at. The thing Linux has going for it is it’s user base. Almost all of which are technically competent enough and motivated enough to seek out problemns when they find them, and if they can’t fix them, find those who can. There are far more programmers working on the disperate parts of Linux than all the coders Microsoft has put together. For the most part they don’t get paid, don’t get stock options, and do it for the adjulation and respect of thier peers.

    It’s no longer "cool" to work at Microsoft, and the more people that come up through the ranks who chooose to invest intellectualy in Linux, the less talented people Microsoft is able to hire for it’s own ends. Look at Google, they have more Phd’s on staff than any other company, and they use UNIX. It’s all about mindshare. We in the western world have a largely shrinking poulation, which means less geeks to go around. This is nothing the clerk using Excel knows anything about, but it’s beginnging to register on Microsoft’s radar.

    http://www.linuxjournal.com/article.php?sid=7637

    "Houston we have a problem" To quote the system monitor behind me 😛

    Enjoy your evening.

  82. jmcelroy says:

    "12. Portability is for canoes."

    Do you not realize how stupid/short sited this is in a rapidly changing corporate environment ?!?

  83. Master Norg says:

    2 Rules of thumb:

    Make plan

    Make software

    The rest is bullshit

  84. Bill says:

    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.

  85. Tuco says:

    Can a development team at Microsoft influence the End User Licence Agreement that shipped with the Windows OS? That is what keeps Windows off my box. Parts of items 1, 7 and 12 are just too unacceptable with the XP EULA and I have to press NO when prompted.

    Thanx for sharing this information though.

  86. geek_12 says:

    Ship mode? WTF is this? I thought this was about programming, not some weirdo religion.

  87. Developer says:

    I take issue with #6: "Beware of a guy in a room".

    While the risks associated with such contributors are great (and should certainly not be discounted), so can be the rewards: 1) saving a project that has snagged on a problem for which there is no known solution, thus you have to abandon the project or find one. 2) The creation of an as-yet unseen "uberfeature" that distinguishes the product from the competition (and yes, this is over-design, from such creative fires are patents granted).

    The key is to (1) understand the risk (which is high), and (2) if the risk is intolerable, keep such individuals off the critical path, saving them for a useful but not necessary, "wild card" gamble that might pay off but is no big deal if it doesn’t.

    I can’t help but keep thinking that one Linus Torvalds was a "guy in a room". The effect of such people (whether on your team, or not), can be extreme in both good or bad ways for you.

  88. HHHH says:

    What’s up with the Zen/buddhist rules? Unity, balanace, variation? What about enlightenment? Can I find myself through software?

    Some of the rules are great, but some are total crap. I doubt these are official MS rules, and are "some guys opinion".

    I give it a mixed review.

  89. anonymous says:

    Better leave this article to Microsoft employees and make revenue out of their buggy products.

  90. Xyrus says:

    The fundamental problem with software is that it is logical. Every step must be filled in with right logic for execution to flow smootly and correctly through the software.

    We (developers) are not 100% logical. We overlook steps, or we rely on steps that may not be there. We may take condition A and B into consideration, but we may forget C and not even know a D exists.

    I would like to add another Rule Of Thumb: Chaos Theory: Your designs will never be good enough. Pad your developement estimates accordingly.

    It is impossible for any developer or group of developers to know every side-effect their designs/code will have. Schedule a design phase, but don’t overkill the designs. You’re human, you will miss something. The larger the task, the more likely it is you will miss something. The more detailed you make a design, the more likely it is you will miss something.

    Process is only as good as the people who implement it. Process will not make a bad programmer a good programmer, nor will it make a good programmer a great programmer. However, it may help put resources in the right places for a smoother developement cycle and possibly show areas where improvements could be made.

    For example, this could be the process of a great painter. A great painter may sit and reflect on a scene for days, get the materials necessary for painting, sketch the general form of the painting onto the canvas, paint the scene with some enhancements, and finally touch up the painting.

    Could anyone follow this process. Certainly. Could anyone make a painting following it? Sure. Can everyone following this process make brilliant masterpieces? Not really.

    Software engineering is as much an art as a science. And in being an art, it inherits the trait of not being perfect (a.k.a versions). Mistakes will be made. Some will be caught, others will slip by, some will be "painted over".

    And testing will only do so much to help. It will help reduce the number of glaring defects, but your product will never be tested to the extent that you can ensure 30 million n00bies that your software will have no issues (design or otherwise).

    And one more rule:

    0. NO STRESS! This is the utmost important rule. Stress mentally, emotionally, and physiologically inhibits creativity, productivity, and undermines moral. The stress chemicals released by the brain are for fight-or-flight, not think-and-create. Anyone suffering from test-anxiety can assure of this. The lower the stress level, the happier people will be. This leads to people being more creative and productive. This should be at the core of any process (and indeed work in general). When everyone on the team is in good spirits, you will be amazed at what gets accomplished.

    ~X~

  91. If you want the world to perceve you as correct, make sure you talk about your topic in a way that makes subjective observations appear as fact.

    Bravo, jackass!

  92. ConceptJunkie says:

    I can’t find the step that accounts for the fact that Outlook 2003 can ship even though it randomly trashes data in PST files over a gigabyte to a gigabyte and a half… or the fact that it is literally an order of magnitude slower than Outlook Express, which _can_ handle that much data.

    Microsoft can’t even compete with themselves when it comes to quality. Of course, when you are an unchallenged monopoly for over 10 years, you can get away with this stuff… or even worse, you are challenged by the government, and they let you off.

    Testing is a good plan, but how is it that I experience serious bugs within an hour of installing Windows. Explorer debuted in Windows 95, and it is still broken.

    If you ask me Rule 22 is to finish features that allow marketing to put another checkmark on their list regardless of whether important stuff actaully works or not.

    Rule 23 is to develop a Virus Writers Development Kit (a.k.a. Office) and then try to build good PR by fixing problems that should have never happened in the first place.

    Rule 24: Every app must be expanded until it can be used as a vehicle for a virus that can trash the system. (In fact, no app is useful _unless_ it can be used as a virus vehicle. If MS wrote edlin today it would have scripting that could be used to access kernel functions via TCP/IP.)

    Rule 25: Flexibility in UI is acceptable, but defaults must confuse new users and frustrate experienced ones.

    Rule 26: GUI standards are no longer necessary. Shiny objects are always user-friendly. (This applies to just about every company).

    Rule 27: No useful thing can be designed unless by committee. Consistency and clarity are not signs of maturity. Simplicity is for amateurs. (Breaking up Microsoft would have about as much effect as asking a blind guy if he would not look over people’s shoulders during the final exam.)

    Rule 28: Security has less "gee-whiz" factor than skinning and is therefore a less important feature. (Plus it’s just too darn much trouble to check each memory buffer copy, especially when we’d rather spend time making the media player look like eyeballs.)

    Rule 29: Dominating a market is the same as excelling in a market ("Economic might makes right", or more simply "A monopoly means God smiles on everything you do."). Throwing 10 figures at a market to dominate it is synonymous with "innovation" even when no actual innovation occurs.

  93. Chris Litchfield says:

    This is very good except for the major emphasis on micromanaging. I have found that Micromanaging is a sign of a horrible management team and a lack of trust/respect in the developers.

    A Management team needs to know what resources it has at its disposal. By micromanaging the team, you are admitting you have no clue what you have at your disposal. If a programmer who can deliver and has delivered in the past is micromanaged to the point they cannot deliver anymore due to having to attend meetings, and answer up to every line of code they develop.. its a huge loss of productivity.

    A Management team can KNOW what is going on in the development through natural communication pathways, and normal scheduled smaller meetings. If a meeting has more than 5 developers in it, it had better not be a programming meeting.

    Morale is a huge factor in programming. Programming is as much Art as Science (as you allude to in your "experimentation" statments) and Artists can be excentric. This is good and bad thing but mostly a good thing because the perfectionistic feeling of artists.

    In Synopsis: Avoid Micromanaging, Know your resources, Utlizite smaller meetings and let the knowledge flow.

    Chris Litchfield

  94. derfeind says:

    Everything sounded really nice. But if you are not a programmer in a big company, lets face it, all things he said, are mostly sweet dream.

    Rule: Don´t know what you don´t know

    How on earth will you be able to learn something new by coding? Getting a contract is like getting a job: Half knowledge, half gambling.

    When have you ever met a manager that really knows whats going on? Or that really gives one rats ass about developers ranting about too little time, too shady specs or every other thing, even if they are right?

    Have you ever met a customer who cares about why his needs and schedule cannot be met?

    Also: Have you ever thought about what you would do differently, if you were a manager or sales person? Of course, you say, you would make everything differently. But I tell you, you wouldn´t. Not with paying customers breating down your neck. Equally you would´t really do anything differently if you were customer rather than developer. You would demand usable shipment on schedule. Noting less.

    Developing software is doing stuff for paying customers. Whatever fancy name you might invent for the latest, greatest developement technique:

    Money talks, garbage walks.

  95. Jason says:

    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.

  96. YBM says:

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

  97. Louis says:

    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.

  98. Johnny says:

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

  99. Tyler Durden says:

    Rule 1: Don’t talk about Fight Club

    Rule 2: Don’t talk about Fight Club

  100. GuardianLurker says:

    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.

  101. Dave Fayram says:

    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.

  102. danmart says:

    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.

  103. P. H. B. says:

    These 21 steps are good. Project managment isn’t programming and programming isn’t project management. Great PM’s are rarely great programmers and visa versa. So when a programmer is critical of PM techniques….

    There are a few other salient facts to keep in mind guys:

    1. Whatever works, works. If your software development methodology works for you, or you team – then it works. M$ thinks this works for them, so do I. I’d be willing to bet all of Bill Gates money that NO software developed by M$ up to about a year ago, had security as a design feature. So why oh why are so many using the lack of security as an example of how this doesn’t work?

    2. The second fact is, deliver only what is to be delivered. If security ain’t on your plan, then it AIN’T ON YOUR PLAN. Have a plan. Stick to. If you plan is to exclude something, say that explicitly – ‘portability is for canoes’. So what that *YOU* think this is a bad idea. It is part of the plan. If you are on the team that has a plan that says "protability is for canoes’ either a) accept it embrace it and do it; or b) find another job!

    3. Beware the man (or women) in the room! You bet! As a manager maybe I have supervised two or three programmers I would ever trust to go off and work independently and alone for weeks at a time. (and I ain’t one of them, neither are most of you). This is out of maybe 50 or so programmers. Say 5%. The rest, the 95% have to be watched, monitored, baby-sat, ‘micro-managed’, what ever you want to call it because they have one of more of the following flaws:

    – they don’t under the business we are in

    – they are lazy

    – they are incredibily concieted, because they know how to *whatever* and nearly everyone on the planet can’t equals they are smarted than everyone else.

    – they can’t follow orders

    – they won’t follow orders

    – they rebel at the thought of orders

    – they know better than the plan

    – YEAH! this feature would be cool to add

    – etc etc etc

    That "Phil Khan" level of programmer is really rare, and it is almost a certaintity that it isn’t anyone who reads this post, no matter what you think of yourself.

    4. Communicate, communicate, communicate and communicate. When done with the above, then communicate again, and repeat the above repeatly. However you do this is find. If it’s the ‘triangle’ use that. If it’s ‘ship mode’ use that, if it’s bug lists, use that. Hell use em all.

    5. Never commit to a date too early. If you think you’ll be done in two days, say a few weeks. If you think a week, say a few months, if you think a month, say a few quarters. When pressed to give a date, ESPECIALLY a date that "isn’t a committment" DO NOT GIVE A DATE. The hardest part of project management is early committment lock-in. This is, in my opinion, the fundamental reason most projects fail. Most projects don’t fail because of technical issues, but because of too early committment to dates, which defines then a failure, or creates one when the project is re-scoped or new resource is added to ‘make-up’ the time behind schedule. It is a self-fulfilling (failure) prophecy. The 1st point is not just a point, but the most important.

    2 cents.

  104. Tom B says:

    Slashdot has posted the link on these 21 rules of thumb and it’s really unfortunate.

    This army of open-source capitalism haters clearly doesn’t get the point. To them it’s just another excuse to bash Microsoft.

    “Linux is great, penguins make great pets”… blah blah blah

    Go hug a tree or save a whale or something… just don’t keep boring us with the same tired “Microsoft sucks" themes.

  105. P. H. B. says:

    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.

  106. dasmegabyte says:

    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.

  107. Hell, I don’t have any projects in mind, but show me a tech team that followed that set of rules and I’d hire ’em on spec…

  108. You will still turn out crap as long as you don’t understand the difference between an Object and a Relationship.

    I’ve worked on a system with ~750 objects and another system with ~450 real object (and 300 objects that shouldn’t have been there but were because the developpers had never heard of a STATE MACHINE,) and in those systems and many others, the important part was totally omitted.

    The systems weighed in at ~1,200 Relationships. That is Relationships, not relational links maintained through foreign keys embedded in an object deinition.

    Those objects were clumsy, required lots of maintenance, had version compatibility problems and the software never seemed to be finished because they couldn’t see the difference and so they were trapped in endless versioning of objects.

    If you handle Relationships as relationships, all of that crap goes away. An object can be itself and neither know or care about the relationships its participating in, unless it makes business sense to do so.

    Maintence becomes a lot easier too because Relationships are existential (some thing is connected or it isn’t.)

    It all comes down to a Schema. The schema can be used to generate most of the software. Objects rarely change, (a brick’s a brick) but the relationships in which it can participate, the connections it can form, is the source of the system architecture.

    There is one rule of thumb embodied in one phrase:

    Nany, Any, Many

    Nany: How do I create an object? (What context of other objects is required.)

    Any: How do I manipulate this object? (Where coding is still required, just not as much or as frequently. [Objects are like bricks: reusable.])

    Many: How do I connect with other objects? [0|]1[N]:<relationship>:[0|]1[N]

    The rest is just icing adn decoretion.

  109. shooby says:

    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.

  110. coreman says:

    Stres? Nothing focuses the mind quite like a gun pointed at one’s chest, or a rapidly approaching ship date.

  111. in defense of that guy... says:

    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

  112. mike k says:

    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.

  113. dasmegabyte says:

    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.

  114. doug says:

    How Microsoft develops its Software. it doesn’t matter. the general public is so gullible they will buy anything.

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

  116. alan says:

    Please use something like QT as an example to follow… not MS.

  117. Chiko says:

    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?

    * Absolutely yes. Linux is no counter example, because Linux has copied the interface of Unix, but now that Linux is even bigger than Unix, Linux is growing very slowly in features. The same happens with OpenOffice, once they have ripped apart Office, they will have to invent, and invention is a slow and buggy process.

    * Microsft releases its products before they are ready for the same reason Intel releases its hardware before they are ready: Market share. Once you grab the market share, competitors do not have a motivation to compete. This will happen eventually with Windows against Linux. Linux is free, then Linux marketshare will eventually surpass Windows’, then there will be no reason to use Windows.

    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 delivers results. You are just confused with software that was released early.

    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.

    * Yes. Microsoft does exactly that. But that has a purpose: Get a marketshare, get mindshare, improve the product, deliver an upgrade which is not free, etc. A money making business usually is not concerned about releasing zero defect products or products that will last forever. Linux is here to change all that, because there is no motivation in free software to release low quality. Customers think: Nothing spent, I can use something else. So whenever the wuality of open source is less than ideal, they look for a replacement. Hackers can patch the same software and make that patch available. High ego plays an important role here, because nothing is returned back to that lonely hacker.

    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.

    * Absolutely. Open Source can’t deliver low quality products or otherwise customers look else where. Open Source will triumph just because of economics.

    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.

    * That is a very good point of view. Microsoft makes a lot of money, I suppose that counts too. If you copy Microsoft probably you won’t get the best products on time, but you will make a lot of money and then buy your competitors.

  118. IS says:

    <i>Shipping great software on time is a difficult but not impossible task.</i>

    How come then Microsoft never ships products on time?

  119. Peter says:

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

  120. John Lennon says:

    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.

  121. Decrepit Entity Bean says:

    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.

  122. Peter says:

    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.

  123. Tuco says:

    "… 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!

  124. Enzo Romeo says:

    He forgot #22. Leave a large security hole in software, or better yet, many security holes. The true hallmark of a "great" Microsoft product.

  125. Not from Slashdot says:

    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.

  126. dasmegabyte says:

    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. There are rarely any security bugs in the WEB portion of IIS. In the, admittedly shitty, free air example, IIS would be Brand $’s sweet smelling air, and Apache would be just the oxygen. Great if you’re looking to breathe. Not so great if your PLANTS are looking to breathe.

  127. Peter da Silva says:

    Some comments for the people who took exception to my comment about portability.

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

    1. There’s a difference between "don’t use any extra features" and "design for portability". Designing for portability is in a large part a matter of good design: figuring out where you need to use enhanced features should just fall out of figuring out how to factor the components of the program. If you don’t *know* what features of the operating environment you depend on, then you don’t know what your program is doing or how it’s built in the first place.

    2. Non-standard features of an environment tend to be a drag on the maintainers of that environment, and the first things against the wall when THEY have a major release. I’ve found that over and over again, the very features I’ve criticised developers for depending on have turned out to require a death march when the development platform went through an upheaval. More on that later.

    "While the development effort for portability is a known quantity, and quite doable (assuming you don’t care much about a rich UI experience), the cost of test is huge and far outweighs the cost of development."

    I haven’t found a necessary relationship between "a rich user experience" and the portability of the underlying code, nor between "a rich user experience" and the quality of the resulting software.

    Consider Mozilla: for portability’s sake, they built their own GUI and run the same environment on Mac OS X, Linux, and Windows… and the result is a far richer and more powerful browser than *anyone* else has, and their Firefox "technology preview" is configurable to an amazing degree.

    On the other hand, consider the many applications that made "rich" use of the Windows 9x environment instead of using the generic Win32 API, and thus had to be significantly rewritten on Windows XP to conform to the new GUI and UI guidelines.

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

    The biggest bone of contention is still "portability is for canoes", and we’ve all suffered from that attiude from Sun as wall as Microsoft. "All the world’s a VAX/Solaris/RedHat" is a cliche for a reason.

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

    No, the point to Microsoft development has always been to support legacy operating systems forever, well, at least until recently:

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

  128. Peter da Silva says:

    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…

  129. From /. says:

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

    Yes, public scrutiny can be a bitch. But don’t turn a blind eye to it. There are both good and bad comments here. And since everyone using a computer is a potential MS customer, MS should listen to what customers want and have to say. If someone doesn’t like a MS product, MS should be asking why. Maybe the EULA is too harsh, maybe the company’s public image is bad or maybe someone doesn’t like the software for a specific reason.

    If you put your head in the sand, then you’ll never know why.

  130. Elo says:

    There is great deal of wisdom in this article, but it is the wisdom of organizing a large number of people to successfully deliver "something".

    It is not the wisdom of building "something that the customer loves". The "enrapture the customer" section is where the wisdom of building what a customer loves should be.

    "Most software is a renewal business." OK. No. That is dead wrong. The _company_, Microsoft, is a "renewal business". Over 60% of the companies revenue is Windows renewal fees, and that is the problem. Great software is not a renewal business.

    Really great software that meets the needs of the customer and engenders customer loyalty is not a renewal revenue stream. I know many people that continue to swear by Word 5.1, and I know many people that have used the Vi editor for over 20 years and remain blissfully content.

    Sucking money out of customers and making customers happy are not the same.

    The reality is that streamlining core application functionality and leaving what works well enough alone is not an effective way to suck money out of a customer on a recurring basis.

    The result is that Microsoft and any "revenue stream" company that seeks to compete with Microsoft is reduced to trying to "enrapture the customer" with fancy gadgets and arcane functionality. 5% of the users may actually use fancy gadget A, but 100% of the users pay for it. I call that the "cool shit ad campaign" software development process. And the second word in that sentence is the most accurate one.

    And so it goes. Every person that takes issue with Microsoft for product quality, is taking issue for this reason: Microsoft product quality is optimized for sucking money out of a person’s wallet, rather than providing the user with a truly effortless and enjoyable way to do what they need to do.

  131. hh says:

    No wonder windoze is a crappy os

  132. Charles says:

    I think the tone of the comment you are receiving will give you some insight into how unpopular Microsoft have become. Microsofts attempts to take over and lockin the industry has not worked, and to the extent lockin has worked you have temporary and angry customers.

    People don’t like being a customer because they have to. I suspect Microsofts attempts to lockin the server market will threaten Microsofts core products. Windows is a good client,if Microsoft worked hard to make it compatible with all servers it would be a great client.

    Linux tries to work with all. Microsoft claim a victory because they have stopped the Samber team developing code that supports Windows clients. What absolute stupidity.

    Microsofts active directory; useless; it can’t be used in a mixed environment. The Microsoft implementation of Kerbose, a complete waste of time for the same reason.

    Microsoft is a successful company, because they are big their bad behavior has cost many software developers wasted days, and cost the economy billions. Working around Microsoft attempted lock in takes time and money.

    The lock in and incompatibility built into the Microsoft offering makes them less useful, cost the industry money and wastes every ones time. I think many are fed up.

    I want to continue using Windows as a client, but I am not willing to put up with the shit we have seen out of Microsoft in recent years.

    If this continues I will be switching to linux not because it is more secure, not because it is more stable, but because it tries to play well with others.

    That is the issue for me, I am not really interested if the developers think they are developing great software. Given the lack of security and the reliability of the window OS family I suspect you are self deluded but that is another issue.

    Regards

  133. taco says:

    This is a useless comment.

  134. Boris says:

    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.

  135. pabtro says:

    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.

  136. Tuco says:

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

  137. YW Law says:

    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

  138. Hexatron says:

    Much of our speech consists of words that just fill the space between other [damn] words, and [actually] do not add anything to the statement [really, I know, what I mean is, you know what I’m saying].

    Microsoft speech is glutted with several such noises:

    great — a meaningless interjection

    cool — another meaningless interjection

    fantastic — almost meaningless. It may weakly imply ‘nonexistant’.

  139. Chil Out says:

    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!

  140. Frank says:

    Great products — like Windows ME ???

  141. Get a grip says:

    I’d be shocked if anyone actually posting this drivel have actually ever worked on anything of the size, ubiquty, and complexity (I’ll take even 2 of the 3) of the MS developer suite or Office products.

    The _reality_ is the business of software. As irritating as that may be (as it is to "artists" who deride the business of art), it is revenue stream, "lock-in", etc. We all eat. We all must pay extortion to the oil refineries. Open your eyes and tilt at those windmills: companies whose PROFIT is measured in billions.

    For those who think "portability" refers to supporting *nix, grow up and open your eyes. Jim wasn’t referring to portability in that sense- try portability in terms of a single code base for Mac (Toolbox-days- this stuff is OLD) + Win API + *nix. These things come from a period in time when Borland (with Philippe still around) was touting OWL as an answer…

    OK, so I sound like an old fart. Well, I am- and I’ll apologize once I see one of the blinded newbies admit they are…

  142. Boule75 says:

    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…

  143. JM says:

    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.

  144. praxis22 says:

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

  145. no two says:

    Get this MS crap from javablogs. The people lose billions dollars using MS "software" just because the quality of design and testing was sacrifies for the sake of "marketing".

  146. This is pretty dumb-ass article, it doesn’t say anything new and does a pretty poor presentation of things that are well understood.

  147. Slick Mick says:

    "Wow, the Slashdot loonies are out.

    And they wonder why Linux never goes anyplace fast…

    Smart move guys."

    Linux never goes any place fast? Where have you been for the last 15 years? How many releases of Windows do Microsoft get out in comparison to the major linux distros? How long does it take for service packs to get out? How much market share has Linux taken on the server market?

    You must be in denial, as your ambivalence towards slashdotters is truely purile, I bet you haven’t even read half of the stuff written. Sure there are slashdot zealots, but you guys are just as bad coming from the extreme right wing.

    Once again it is all about choice. There are some valid point in this methodology, the fact that it comes from a Microsoft employee is ancillary , be it not somewhat amusing. It is always a pleasure to see how other people do it, if it works for Microsoft then thats good for them.

    I think these days the pressure to produce products is definatley taking the front seat from reliability and robustness. If I bought a car that was similar in quality to some major software products these days I would be truly dissapointed.

    I think that is the value of taking software out of a commercial profit making structure, less business pressure means higher quality code, but then again it means less pressure on time lines. But then again that means less money on maintenance and fixing everything up.

    I think commidity software has been the downfall of reliability. Quality software is created when the objective is to satisfy a need, not to make money. If the software is crucial to the individual business, then it will generally do its job and do it well.

    Anyway, enough of ranting about ideals of the software industry. It makes me look like a loonie.

  148. SrSwEng says:

    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.

  149. Alexendra says:

    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.

  150. Yes, I’m one of the Slashdot crowd, but that doesn’t mean I’m a Linux fanboy. I admit to running Windows even at home, where I have a choice. It’s there, and it’s Good Enough (TM). Please accept this as evidence that I’m neither a MS apologist nor a Linux zealot.

    People are commenting that Microsoftware isn’t really great because it has many bugs. I agree, but I’d like to point out the reason:

    Microsoft is a CORPORATION, not an organization for the advancement of the good of humanity. We need to understand that this means: Microsoft’s mission is NOT to make great (or even good) software. Microsoft’s mission is to make MONEY. With respect to fulfilling its mission, Microsoft is insanely great!

    Making software is incidental, it’s a means to an end. In many cases, making good software would interfere with the mission.

    For an example outside the software world, take the Mercedes 180: This car, built before I was born, presented a major problem to Daimler-Benz: It was so well made that it rarely broke, and needed almost no maintenance! People who had one seldom bought another because their old one ran and ran… This impacted Mercedes’ bottom line, so they made a conscious decision to reduce the quality of their product.

    Building incompatibilities into Windows (remember DR-DOS?) increased MS’ market share. Building an incompatible browser increased MS’ market share. Failing to decently support Java increased MS’ market share. It’s all part of the mission, and it was successful beyond anyone’s wildest dreams.

    Many of the flaws in MS products can be easily explained when you realize that IT IS NOT MICROSOFT’S MISSION TO MAKE GOOD SOFTWARE!

    Knowing this, and assuming these guidelines really reflect how Microsoft works, please take note that successful application of these rules means making more revenue, not necessarily making "great" software.

  151. izidor says:

    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?

  152. Scott Wilson says:

    When I saw that this was based off an interview with Jim Mccarthy, I thought, "Wow, that explains a lot about Microsoft software." If that self-important BS artist is the embodiment of development principles over there, it goes a long way toward showing how it is that a lot of actually quite good coders can consistently turn out products that are frequently mediocre and broken.

    Reading down that list reveals a lot of managerial Newspeak, one or two not-bad ideas, and a lot of other conceptualizations of the software development process that are (I believe) being steadily discredited by more innovative developers.

  153. Ron says:

    Some excellent points, but taken as a whole very questionable. The question for me, is this competitive disinformation???

    The book of the month crowd who follows this line of thought completely, will go down hook line and sinker; if they do not seriously consider all the laws of unintended consequences.

    If indeed it is true, then Microsoft is even better at marketing than I thought they were.

    It also explains why Microsoft stays away from certain business sectors. It also shows some serious holes, and a great oppurtunity for the next Microsoft, whomever it may be.

  154. Tom Hudson says:

    quote from another poster:

    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.

    — end quote —

    Linux has no chance? When Ballmer says that it’s the number 1 threat?

    Want to tell that to IBM, Novell, etc? Hell, even MS’s sock-puppet SCO thought that there were billions to be made licensing linux.

    If Microsoft made good products, I’d still be using them. They don’t, so I don’t.

    Just look at the browsers: Firefox and Opera (I’ve got both open on different desktops on this computer) are years ahead of anything from Redmond. And with more apps being browser-based, the underlying OS can be anything. This is what has them FUDding all the time.

  155. The rule exists in theater too — "You can have it good, fast, or cheap. Pick any two."

  156. Dr. Neil says:

    Jim McCarthy’s rules and then the extended set published in Dynamics should not be underestimated. They were creating an agile environment for software teams before Agile got a capital A. The RAD approaches to developing software that Jim and his peers took at the beginning of the 1990’s were the precursors to methods we have seen in the last few years becoming popularized, such as extreme programming.

    Whether MS teams use them or not is up to the team. What is interesting is that Jim’s team did use them and was very successful. Visual C++ was a fantastic application; it knocked Borland out of the number one spot at the time.

    The follow on work the McCarthy’s have done as documented in Software For Your Head is the culmination of over 10 years of work and research into helping teams deliver great products on time.

    The thing to learn for all of us is how to achieve this or at least get closer to it.

  157. zone says:

    Geez, I’m glad I’m not a Microsoft programmer. If I spent as much time they probably do listening to project leads preaching the gospel of the latest greatest Extreme Programming techniques/"rules," I’d never have the time to write a single fucking line of code.

    Now that I think about it, twenty thousand programmers seems like an awful lot considering the number of products Microsoft has on the market right now. Even with R&D and their web services. But whatever, I’m certainly not an expert when it comes to running a software company.

  158. Alex says:

    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.

  159. RiotNrrrd says:

    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.

  160. Greg says:

    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.

  161. the 64-th bit says:

    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?

  162. Shari Vegas says:

    Hm. Uh, yeah, great article. Glad it works for Microsoft.

    This doesn’t help for a system administrator who has to patch the Win2k/XP desktops every week. Or the Geek Friend who just gives up on his Non-Geek friend who uses WinME, because the fact is that it’s completely, utterly unstable.

    I use a protected Windows desktop – Zonealarm, Peerguardian, Firefox, Thunderbird, AVG Anti-Virus, Trillian Pro. Administrator has a long-enough password, sharing is disabled, users run as Power Users, and do not have the Administrator password. Guest is disabled. Win2kSP4 with various hotfixes. No, I don’t let Windows Update run, it in itself is inheritly buggy and problematic.

    Out of all this, I still can’t seem to keep my desktop stable and fend virii away. IE6, for example, is permanently stuck with a virus I can’t lose. I’m going to work on letting absolutely NOONE be allowed to run it. Outlook will not delete, and this is officially considered a virus, and I will be disabling access to it. Probly should encrypt the fucker too.

    I’ll stay with Linux. Whatever they’re doing, it’s right, and it works. Whatever Microsoft is doing, is wrong, and costs me many thousands of dollars in time and training costs.

  163. Saulius says:

    Well, a lot of interesting insights on how MS develops its own software. However this 21 rule "collection" seems more like a jumble of "best practices" of project management, software engineering and marketing.

    I want to point out for everyone criticizing these rules that these are best practices of how Microsoft succeeds with its IT products in the marketplace, but not about how to achieve "excellent technical products".

    Microsoft with most of its software products has taken an unbeatable strategy "low prices every day". Yes, to me it’s like Wal-Mart: if there was no Wal-Mart, some of the Americans couldn’t afford to have cheap clothes, cheap electronic and other "cheap" stuff, which is produced in China. Since it’s dirty cheap, nobody expect a high quality out of it.

    Microsoft made the same to personal computing – "computer on every desk, using [cheap] Microsoft software". Nobody promised us quality software, just a cheap one.

    While everything at Wal-Mart is aligned to achieve lowest prices (goods are produced in China, wages are low), the same is about Microsoft – in the software business, rules are different (you simply cannot pay low wage to the smart developer), however you can leverage that by volume and poorer quality (how much does it cost to "produce" extra copy of MS Word?), so it’s no surprise that all Microsoft best practices reflect these optimizations – it’s ok to slip, it’s ok to drop features, it’s ok to have bugs, it’s ok support few platforms. And it works! Just look at Microsoft revenues.

  164. Raffles says:

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

  165. David says:

    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!

  166. Ian says:

    "Re: 5 … Zero defects does not mean that the product does not have bugs, …

    <p>

    I guess this is the opposite side of the coin of "if you can’t fix it, feature it", which gave us the "it’s not a bug, it’s a feature" mentality. A bug is a programming error. Zero defects means zero bugs, zero errors. To even try to argue anything else is to lie.

    <p>"

    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.

  167. P.H.B. Not! says:

    It was rather interesting that the person in the replies who pushed the most for MicroManaging named himself P.H.B. Pointy Haired Bosses tend to have budgets come in way over time and money. The features are different than the requirements and the negotiations with customers are horrendous.

    He mentioned the "Flaws" in Programmers:

    Lets go through these Flaws and address them.

    – they don’t under the business we are in

    This is a function of management not showing the programmers and other works what the product of the business is. A manager insulates the programmer from a lot of issues so that the programmer can focus on requirements. If the requirements are not laid out, then this is NOT the programmers issue.

    – they are lazy

    There are many different types of programmers. You do not judge a programmer by his style but by his output. A "Lazy" programmer may be someone who thinks a lot before he codes/designs. A manager walking by seeing a programmer sitting staring at a wall may think the programmer is "Lazy" but in reality a good/great programmer is 75% thought before action.

    Challenge your staff and dont judge based on style.

    – they are incredibily concieted, because they know how to *whatever* and nearly everyone on the planet can’t equals they are smarted than everyone else.

    Get smarter people. If you dont, you will lose these smart people in the end and end up with slug, dullard programmers that make any manager look bad. Challenging your programmers by bringing in smart people end up making your workplace a haven for smart people. Smart people like being around smart people and conciet goes away.

    If you cannot manage conciet, your are not a smart manager.

    – they can’t follow orders

    Can they follow other manager’s orders or just not yours? Evaluate your performance by thiers.

    Fire them if they dont follow orders at all. Its plain stupid to have programmers who cannot work in a team.

    – they won’t follow orders

    This is even more of a function of Who is the Boss? If programmers are not listened too, engaged in requirement processing, or otherwise disrespected.. why would they want to follow your orders?

    Managers get fired for losing the confidence of the staff. Respect the programmers and some may not deserve it but others rise to the occasion.

    – they rebel at the thought of orders

    Artists rebel. Live with it.

    – they know better than the plan

    Did you listen to them? No? how do you know they are not correct?

    – YEAH! this feature would be cool to add

    Mimization is the function of all who program. This is a function of weak requirements and lack of focus.

    – etc etc etc

    In the end.. MicroManaging, jumping on people, etc etc etc are part of a disfunctional SEI level 0 house.

    Cultivate your staff with decent pay, great environments, Ping Pong, Fooseball, Exercise Bikes, Lunches, Communication, OFFICES (cubicles just kill respect) and you will have a programming staff that is loyal and smart. You will trap the best.

    Our average programming staff at the company I work for has been around for over 15 years. This includes new hires we occasionally bring in who have proved themselves in the University, etc.

    I have been here for over 10 years and when projects get micro managed, they die fast and we LOSE valuable people.

    Why would you stay on a company that does not respect you? In a 2 year average project cycle, losing a single valuable person kicks the project in the schedule and budget. Losing them because of some misguided attempt at micromanaging… is unacceptable.

    Caveat: Managing vs Micro Managing. Micro Managing is constantly stressing out the programmers by reminding them of things they already know on a daily/hourly basis because you are not comfortable with the project.

    MicroManaging = Stress

    Stress = less creativity

    Less Creativity = Slug or Quitting.

  168. Peter da Silva says:

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

  169. Keith Bent says:

    Microsoft has transformed the world. I find that most people who support linux are all network/techi folk who have a very good understanding of computer systems. What they don’t get is what Microsoft does very well, which is to make the product useful to the majority of users who’s ability is pretty much limited to double clicking an icon. Until those in Linux land understand this, it will continue to follow far behind Microsoft. This article is full of important pointers that I wish the Linux comunity would listen too, and pull their head out of the Sand and start developing software that they are more then capable of making. Software that can be used by the greater community.

  170. j.g.owen says:

    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

  171. Carlton Nettleton says:

    The triangle is wrong – there are four variables to software development: resources, features, schedule and QUALITY.

  172. It's the Sign of Someone Who's Too Lazy to Write a says:

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

  173. David Gristwood says:

    "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

  174. Aristothenes says:

    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.

  175. Sikko2Go says:

    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 🙂

  176. Carl says:

    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

  177. Harm Beelen says:

    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.

  178. Ryan says:

    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.

  179. KJ says:

    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.

  180. Peter da Silva says:

    You want critical success factors? Portability, simple design, compartmentalised design, string borders between independent components, well designed, documented, and implemented APIs. Here we are, about 35 years into the development of the UNIX programming environment, and it’s still dominant. Even Microsoft ships a version of UNIX that runs under NT, and uses it internally even if they downplay it.

    I took a program I wrote 20 years ago and recently rediscovered in a source archive, modified a handful of lines of code that I now realise represented a misunderstanding of the API I was writing to, and it still compiles and builds and runs. Not only that, but it runs over a communication link and on file types that didn’t exist 20 years ago, because UNIX uses the same API for local and remote files, network sockets, serial ports, and in fact everything that can ue a stream I/O model.

    I’ve taken a DOS-based program that I wrote at the same time and ported it to UNIX, which wasn’t hard, but it would require significant work to make it run under NT because Windows sockets aren’t like any other stream object.

    Portability. Good APIs that can be widely applied and *are* widely applied. THAT is why UNIX remains a success, despite everything Microsoft has tried to do.

    And…

    Keith Bent: you write "Microsoft has transformed the world."

    I’m sorry, but that’s just not true. Microsoft dawdled, and only produced a usable GUI-based operating system in 1990. They were preceded by Apple, Atari, AT&T, Commodore, … I could go on through the alphabet, if you like. And that’s even ignoring the third-party GUI desktops that ran under DOS like GEM and Desqview.

    … and thanks to Apple we can get the portable UNIX environment *and* a great user interface!

  181. tressa says:

    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.

  182. mc says:

    You might be interested in this link to see more of what Jim is thinking these days

    http://www.softwareforyourhead.com

  183. rackflot says:

    I work in Network Systems of automotive audio componants for a major supplier. It seems that we can break every one of these rules. They all scream out that this is the reality of agressive dates and inadequete planning for the job to be done. By being under resourced, over out sourced and just damn cheap with tools, we shoot ourselves in the foot everytime…

  184. Anonymous says:

    Ashutosh Nilkanth’s Blog &raquo; How Microsoft develops its Software

  185. Bruno Magli says:

    "Specialist developers who lock themselves away in a room, going dark for long stretches, are anathema to shipping great software on time"

    Ahem. I was the guy in the room. I was assigned a project as was this other "team" of consultants. The 2 systems had lots of similarities and function. I finished mine in 5 months. Its been a year and theirs is still not done. In fact they’re contemplating rewriting it. Mine came out with a lots of useful features while theirs was bare minimum. They set out to design a horse but came up with a camel instead. They designed everything by committee.

    My point being is this. The optimum number of software developers in a team is ONE.

    For a huge project divide it into subsystems, with each sub sytem enough for a single programmer to handle. The architect sets up a basic framework for everyone to follow (ie how to build the data access layers and etc) and then let loose. If you get a programmer that cant even design as much as build the subsystem then dont blame the programmer. Blame the incompetent HR person who recruited him/her in the first place.

    The art is in how you divide the project into subsytems and the basic framework you use to build it.

  186. Bruno Magli says:

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

  187. Bruno Magli says:

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

  188. Anonymous says:

    Marc Nozell’s mini-blog &raquo; funny NSFW story

  189. Anonymous says:

    ChaosElbows &raquo;

  190. The original article of Jim McCarthy. The book he wrote is &amp;quot;Dynamics of software development&amp;quot;…

Skip to main content