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…