[TMMM] Ch 7 – Why Did The Tower of Babel Fail?

<< Chapter 6: Passing the Word

For those unfamiliar with the story of the Tower of Babel, read about it here: http://en.wikipedia.org/wiki/Tower_of_Babel

A Management Audit of the Tower of Babel

First of all, did the project have the following:

1. A clear mission? Yes, even though it was impossible to do
2. Manpower? Yup
3. Materials? Clay and asphalt are abundant in Mesopotmia, so yeah, they had it
4. Time? Yup, at least, it didn’t sound like they were in any rush
5. Technology? Yes, they knew how to build ziggurats

So what went wrong?  Everything was in their favor!  They lacked two things: communication and organization

Communication in the Large Programming Project

Problems occur due to a lack of communication.  As the saying goes, the left hand doesn’t know what the right is doing.

There are three ways that a team can communicate:

1. Informally – telephone calls, chats, etc.
2. Meetings – regular project meetings, technical briefings, etc.
3. Workbook – a formal project workbook, which is explained below

The Project Workbook

What

The project workbook is a structure/framework for all documents.  This includes objectives, external specs, interface specs, technical standards, internal specs, administrative memos, etc.

Why

The project workbook ensures that the documentation structure is well crafted and not haphazard.  The structure of the project molds future writings into segments that fit into the strcuture.

The project workbook also controls the distribution of information.  The idea is not to restrict information flow, but to ensure that relevant information gets to all the people who need it.

Mechanics

The difficulty of maintaining a project workbook increases non-linearly with the # of people involved.

It is essential that every programmer sees all of the material in the workbook.  It is essential that the workbook is kept up-to-date as well.

When organizing a large project, two questions naturally raise: what has been changed, and what is the definition today?

This can be addressed by marking changed text on the updated page.  Changelogs should be written along with updated pages so people can see the purposes and significance of changes.

How Would One Do It Today?

Digitally, of course.  The project workbook should be digital, with change bars and revision dates.

The change log should also be digital, recorded in LIFO ordering.

More importantly, the workbook should be accessible to everyone.

Organization in the Large Programming Project

Given n workers, there are (n^2 – n)/2 interfaces across which there any be communications.  There are potentially 2^n teams which require coordination as well.  You want to find the most efficient means of communication when dealing with this kind of scale.

Communication between teams can be reduced by division of labor, and specialization of function.  This can be achieved through a tree structure.

“The tree-like structure of organizations reflects the diminishing need for detailed communication when division and specialization of labor are applied”

In a tree-like organization, it is essential that every subtree  has:

• a mission
• a produce
• a technical director/architect
• a schedule
• a division of labor
• interface definitions among the parts

Producer assembles the team, divides the work, establishes the schedule.  He acquires resources, and establishes the pattern of communication and reporting within the team.  He ensures that the schdule is met, shifting resources and organization to respond to changing circumstances

Technical Director conceives of the design to be build, identifies its sub parts, specifies how it will look from the outside and sketches the internal structure. The technical director ensures unity and conceptual integrity, his work is almost 100% technical and within the team.

Given these two key roles, there are three possible arrangements:

Producer and technical director are the same person

This is a common arrangement for small teams.  However, this doesn’t work very well for large teams.  It is hard to find a person who is very good at technical matters and is also a good manager.  “Thinkers are rare, doers are rarer, thinker-doers are rarest”

Also, when the project gets bigger, it is harder to do both roles since both are full time jobs.  Eventually, the producer/director will be overwhelmed and the project will suffer.

Producer is boss, technical director his right-hand man

In this arrangement, it is necessary to establish the director’s authority to make technical decisions without impacting his time.  The producer must ensure that the director, although outside of the management line, is a source of decision power.

The producer must back the director 100%.  Because of this, they must agree on technical philosophies so that they can operate efficiently.

The director is the boss, and the producer his right-hand man

In this arrangement, the director is given free reign over the project.  The book has a lovely example of it, I won’t bother repeating it here.  Nevertheless, the situation is familiar enough that we’ve seen such arrangements in modern day soft-dev shops.

Chapter 8: Calling the Shot >>