Jeff Vilimek

At least once a year I personally revisit some brilliant software development best practices outlined by Jim McCarthy at Microsoft in the mid ’90s. Not long after it was released in its original format as an internal presentation, Jim published a version in the book Dynamics of Software Development and left Microsoft to establish a company focused on training software development teams. His guidance continues to live on at http://www.mccarthyshow.com in a couple newer books, webcasts, and training sessions.

This stuff is easily consumed and I recommend it for any software development team. It’s filled with excellent gems of knowledge that are easily adapted and applied to any project. I’ll go into some of the highlights here but that original presentation that I saw in person back in 1995 is available as a slightly edited series of webcasts up on Jim’s web site.

The Original Presentation

Back around 1995, Jim McCarthy was a program manager at Microsoft responsible for the Visual C++ product development effort. He and a couple other smart people took that development team from what Bill Gates once called the "stupidest guys in the company" to a high performance group that shipped high quality software on time.

Being a guy who loved to make top 10 style lists back then he also took some time to make a list of what he called the "Rules of Thumb For Shipping Great Software on Time." This turned into a presentation for some of the product groups and eventually got to the Microsoft Consulting Services world summit where I and a room full of all five hundred Microsoft Consultants in the company at the time got to hear it from Jim. The webcasts I mentioned above are actually taken from a video of that original session, however, I prefer my original, unedited version!

My Favorite Rules

• Lucid Ignorance: Know that you don’t know and plan around that uncertainty. Don’t pretend to know what you don’t know.
• Get to a known state and stay there: If you took a finished product and had to add just a single small feature then planning, integration, testing, etc. would be easy. If you structure your whole project from the start this way and keep it tight as you go along you can gain a lot.
• Never trade a bad date for an equally bad date: Slipping can happen, but don’t hemorrhage even more credibility by throwing out a new date that you won’t likely meet.
• Cycle rapidly: It’s unlikely that the business/customer problem you are trying to solve is static. If you plan around iterations you’ll have a better chance of keeping on target.

Great material. Highly recommended. I’ll be setting up a lunch session for my team in the next couple weeks to watch the original video. Let me know if you want to join us!

What software development guidance, gems, best practices do you recommend?

Filed under:
Development by Jeff Vilimek