Much of the wisdom relating to the development process is well known, but it deserves repeating. Often the difference between in and out of control is in the details.
Virtually every team at Microsoft divides their projects into milestones and uses these milestones to track the progress of their development. However, many teams also cheat on their milestones, which of course only causes problems down the line.
There are several common milestone cheats:
n Fudging the end date (“we didn’t really say the 3rd, we said ‘August’”)
n Declaring victory (“well most of the team made it”)
n Not having definitive quality objectives (“so what if we have 1,500 bugs, the code is complete”)
n Moving things that didn’t make it into the next milestone without careful evaluation, and without a complete reschedule of the rest of the project.
Teams also commonly fail to come to closure on milestones by not holding milestone reviews. These reviews, also referred to as milestone post-mortems, are extremely important sources of corrective action for the next milestone. Failure to hold them, or to reset the schedule during them, is a serious warning sign.
Time has shown the daily build of the product to be one of the most important diagnostic tools for the health of the product. Having a daily build does not ensure the health of the project, but few well-run projects survive without one.
Key to the daily build are the daily sniff tests (or smoke tests). Stolen from the electronics industry where people would plug in a board and see what smoked (or smelled bad), sniff tests are a vital part of the build.
These tests ensure the basic stability of the product by checking daily that nothing has been checked in that jeopardizes the basic product. If something is uncovered, it is repaired immediately. This provides a foundation for the new work to be added each day, and ensures that the project doesn’t stray too far from a stable working version, requiring days of corrective measures.
Sniff tests should also be built to be run by the developers before checking in code. This prevents breaking the daily build and also encourages developers to take more responsibility for the stability of the product.
The importance of a regular (preferably daily) build cannot be underestimated. A good way of thinking about this is to consider how much time it would take to recover from a fatal flaw in a check-in. If you build weekly, and someone checks in something stupid on Monday that you don’t find until you build on Friday, a week of work might have to be repaired before health is restored. You’ve lost two weeks. If you built daily, it would be two days.
It’s also important to start daily builds very early in the process, preferably from day one on new versions of existing projects. Think of it as getting the project to a known state and ensuring that it stays there.
Eating your own dog food, that is making your team run, live, and breathe their own product, has been shown to be a vital method of ensuring the health of a project. Some people claim that this is only viable with apps people use in their daily life (such as the operating system, or a compiler), but the reality is that you can make daily and frequent use of the product a key goal for every team member.
You can achieve dog food in a variety of ways. Have a database? Use it to track your bugs. Have a spreadsheet? Use it for your schedule. Have a game? Make sure people are using it daily, taking it home, and sharing with their friends.
Dogfooding is so important that some teams can actually judge the ship date from the day they first start seriously doing it. For example, operating systems, some feel, are a year from release when dogfooding begins. Whatever your metric, if you’re not doing it, you’re in trouble.