21 Rules of Thumb - How Microsoft Develops its Software
Best blog entry ever? It is possible.
This morning's edition of David Gristwood's blog boasts an absolute gem entitled 21 Rules of Thumb - How Microsoft Develops its Software. The item, originally written by Jim McCarthy, deals with how to get a team to gel, be productive, and produce great software. To be perfectly frank, I feel extremely validated reading it. Most of the things on his list are things that I have pushed for at development jobs over the years, but have rarely gotten through official channels (although I usually implemented similar practices on whatever team I happened to lead anyway). Now that I run my own company, however, I can implement any development guidelines I like. Let's look at the top 3 items from Microsoft's playbook:
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.
Here we have a classic example of one of the 5 Pitfalls of estimating projects - Pitfall #4, to be exact. This is arguably the most important concept in the whole industry - eliminate the unknowns, and if you cannot eliminate them, acknowledge them as unknowns. I think we're all familiar with the old saying about the word "assume".
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.
There isn't a developer among us who doesn't have at least one war story related to a problem that stemmed from the build being in an unknown state. So far, so good.
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.
OK. Remember when I wrote that eliminating the unknowns was arguably the most important concept of all? I am now arguing with that position. Without fail, the single most destructive act that can be committed on a project is to try to violate the relationship between resources, features and schedule. To do so is to fall right into the fifth of the 5 Pitfalls of estimating a project - taking too large a bite from the apple. It's good to see that MS (or at least, individuals within MS) are acknowledging this publicly.
Those are just the top 3 items from the list; take a look at the remaining items. You'll find things like "Low tech is good", "Beware of a guy in a room" and my personal favorite - "Never trade a bad date for an equally bad date".
Now if only I could answer the question of why so many organizations fight these type of best practices tooth and nail...
10:51 AM
Why the Desktop is Never Going Away
By now we've all read Joel Spolsky's rant on how Microsoft has lost the API war and it's too late and desktop development is dead and web development rules all and everything is going to h-e-double-hockey-sticks in a handbasket. I'm not even going to bother linking to it - you all have either read it, or know where to find it.
Now that Joel has the industry all abuzz with his prognostications of doom for desktop applications, I would like to tell you that the desktop is not going anywhere.
Pointe the first: I am not anti-web. I think web development is a very cool technology, and I can absolutely see the benefits for businesses, although I am convinced that web apps will never catch on with consumers. So as you read this, remember - this is not an anti-web rant. One platform need not die in order for the other to live.
Pointe the second: As you already know by now, NewsGator got funded. Who says VCs are not funding Windows apps anymore?
Pointe the third: Desktop = Power. Nobody - and I mean NOBODY - like the high latency of your typical web app. They simply do not. Sure, Gmail has managed a reasonably snappy interface, but it is still nothing like having "real" software living on your computer. Users like horsepower. Users like ownership. Users like systems that react as quickly as one can click the mouse. Period. And even ASP.NET, as cool as it is, cannot give that to them.
Pointe the Fourth: Users do not trust computers in general; the relative level of trust is inversely related to how physically close the computer is. By far, the number one objection my clients raise to web apps is this: what if my internet connection/network goes down? Even with the economies of scale inherent in hosted apps, many businesses think them too risky to use. Web apps that are hosted on the company's own intranet do much better in the trust equation, but even then the thought is frightening to some companies. Sure, you can talk about how you're going to build failsafes into their system so that they can keep working under those circumstances, blah blah blah, but by then one of two things has happened - a) the client's eyes have glazed over, or b) they're thinking "so you're going to make the project more expensive just to safeguard against something that should never happen I the first place?" and once you get to that point, you have lost. When an application actually lives on the user's machine, the user feels as though he has a little bit of control over the destiny of his workday.
Pointe the fifth: Consumers still buy lots and lots of software. As dicey a proposition some businesses might consider web apps, the general corporate consensus is that it is OK to use them. But as always consumer behavior is different. Going back to NewsGator, can you imagine an app like that being a web app? How about PhotoShop? CorelDraw? MS Word? WinAmp? There's no way.
To be fair, as long as I am pointing out the shortcomings of web apps, I should also say that the desktop does need to do some work. Although it enjoys the advantages of psychology and power, it needs to improve in the arenas that the web truly excels at - deployment and portability.
I was talking with Richard Caetano about this just the other day, and we agreed that although the problems of desktop-app deployment can be cured (or at least mitigated well enough to please people), portability is the real problem that the desktop must overcome to remain a viable platform for application usage. How DO you use an app that is installed on your computer, when you are not on your computer? This is the questions that nobody seems to have an answer for yet. Perhaps a next-generation method of hoteling could allow a corporate user to quickly pull an image of his usual desktop onto a "blank slate" PC in a satellite office? I'm not the most qualified person to theorize on this matter, but it is clear that in the war between those who favor the desktop and those who favor the web, the desktop needs to improve its portability at least as much as the web needs to improve its performance.
This is quite the incoherent ramble, and I'm not really saying anything others have not said before. So allow me to wrap up by saying this:
Predictions of the desktop's demise in the application market are premature and overblown. With Whidbey, it is said that Microsoft is betting the company on the desktop. Well, if Bill is willing to bet the company on the desktop then I am willing to bet my career on the desktop. But the beauty of the situation - and the point of my wide-eyed, frothing-at-the-mouth rant - is that nobody HAS to bet anything on any one platform; the universe of potential applications is large enough to support both desktop and web models. To suggest otherwise is to look at the glass as half empty.
Discuss 'Why the Desktop Is never Going Away' here
06:14 AM
