Rickerism

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 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.

Questions

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.

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

Have you documented the architecture, the design and the code well enough so that you 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 you having to explain it in person, then you have written enough documentation. We want documentation, but we do not want too much documentation; the priority is the coding.

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 locater (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?

Engineering is an art of compromise. A team needs to record why it made the critical design decisions the way it did. Such a record prevents the team from repeating the same mistakes again or wasting time researching something that is known not to work. Such a record also captures, either explicitly or implicitly, the assumptions that went into making the decision. That way, when situations change, the team is able to come back and address the decision. What did not work in the past may work in the future. Engineers should be empowered, not shackled, to previous decisions.

Culture

It is common for some people to use knowledge as power over others. “I know something you don’t,” gives some people a sense of superiority. “You have to come to me for that,” has a similar affect. Hoarding knowledge within a company creates an environment of hostility and uncertainty. It also leads to people making bad, ill-informed decisions that adversely effect the company.

Hitbyabus planning creates trust and security within the team. It can lead to a more general culture of shared knowledge. In such a culture, people within the company are able to make smart decisions because they know the strategic context of their actions.

The US Army has a policy called “one up, two down.” It means that every soldier should know the mission of the leader directly above him and know the mission of the soldiers two levels below him. For example, a company commander knows his battalion commander’s mission and he knows the missions of his platoon and squad leaders. Corporations can easily implement a similar policy.