Hitbyabus planning

At XMLSolutions, Paul Lyman would ask the developers, "What is your hit-by-a-bus plan?" The question is quite simple in its intent. If one of your team members is hit by a bus on the way to work one morning, does the rest of the team have enough information at their hands to soldier on without him?

The team would often chuckle at the question. I do not think that they took it very seriously at first. Then on morning it actually happened. Moshe Silverstein, head of the quality assurance team, got hit by a bus on his way to work. His injuries were nothing to major, but enough to send him to the hospital for some x-rays. We were supposed to release a product that day, but no one on the team had a critical password to one of the build systems. As a result, we missed our release by a day. Some readers may think that is no big deal; they are accustomed to missing release dates by weeks. Paul Lyman does not miss a deadline, ever.

I like to call it Hitbyabus planning, first discovered by Dr. Egad Hitbyabus. After Moshe’s incident, the engineers at XMLSolutions took Hitbyabus planning a little more seriously.

Hitbyabus planning achieves positive results within a development team. It makes the team more professional without excessive bureaucracy. We implement processes to achieve more professional results, but often the process becomes the end in and of itself (see The Karenina Principle). By having this one simple question, engineers can focus on the objective and keep the process practical.

Questions

• Here are some examples of how Hitbyabus planning keeps the team practical and professional.

• Have I documented the architecture, the design and the code well enough so that I do not have to be here to explain it?

Note the practicality of the question. There is a benchmark to measure by. The developer knows how much documentation is enough. When a competent member of the team can understand it without me having to explain it in person, then I have written enough documentation. We want documentation, but we do not want too much documentation, otherwise code development suffers.

• Is the process of source control, building and testing documented well enough so that a new person could find things?

Again, the developers have a benchmark to know how much documentation is enough. They do not have to write an introduction to what source control is and why it is important. They do need to give the uniform resource locator (URL) of the source control server and an outline of how the content is organized.

• Are the design decisions shared? Do others know why we did it this way?