Tom DeMarco on “The Collaborative Design Imperative”

Tom DeMarco has written some great books (“Peopleware” is one of my “Eight important books for software developers”). Thus, I was excited to have the opportunity to hear him speak. The following is a summary of a talk Tom DeMarco gave at the OOP Conference in Munich, on Jan 26, 2011. Comments in square brackets are mine.
What is a system?

• Examples of systems: the digestive system, the health care system, the global weather system, political systems, Linux, etc.
• A system is a complex interconnected set of components that act together to achieve some end. [It is arguable how much nature is driven by an end.]
• In software development, two things qualify as systems:
  • the software product that your team is building
  • the project that builds it

Why are [software] systems so hard to understand [and build]?

• Code as a set of messages from the project to the computer.
• Every bit that is in any of these messages has to have been inside a human brain at one time or another.

How much capacity does a brain have?

• Early estimation by von Neumann: 10²⁰
• Later approach to estimation: How much data gets into the brain? Answer: Eye bandwidth (other channels are negligible) is about 10 Mbit/s, but we store much less.
  • This amounts to a brain capacity of about 1GB.
• Thus, we need to collaborate on large projects, to combine brain capacities.

Natural systems versus technical systems:

• Natural systems: big pieces, tightly integrated [“big” as in “complex”]. For example, the human nervous system or hormonal system. We can never really understand natural systems like the two aforementioned ones, because they are too complex and too tightly integrated.
• Successful technical systems: small pieces, loosely integrated.

Designing a system: There are two kinds of design involved.

• Conceptual Design: How a proposed system fits into, interacts with, and alters the reality that surrounds it.
  • Team size: Fred Brooks (DeMarco: “my hero”) has a new book out: “The Design of Design”. In it, he writes that the optimal team size for doing conceptual design is one, at most two (if one of the two is dominant).
• Internal Design: Derivation of an optimal piece structure to achieve the chosen conceptual design
  • Team size: Large teams are needed.
• Due to their size, many software projects set new records regarding human collaboration. This is ironic, as you need to be a loner to become a programmer. That is, you must like to work on problems on your own. [This is how things get started, the whole presentation is about the need to work in teams to really be productive.]

“Trust is the bandwidth of communication” (Karl-Erik Sveiby). Meaning: If you don’t trust the source, you don’t receive information. As an example, DeMarco mentions spam where you completely ignore what is being said, as soon as you recognize it as such.

• Traditional maxim: “Trust is given as trustworthiness is demonstrated”. DeMarco: “Tell that to your kids! But it is a lie.” Instead: Trust must go ahead of demonstrated trustworthiness. You give trust to gain trust. It is how you motivate team members. This goes beyond what is generally considered “professional”. Professional bandwidth is not enough to exchange trust, social interaction is needed. He cites the difficulty to establish trust with outsourced colleagues.
• As an example, DeMarco says that he still remembers all six people in his life that ever gave him more trust than he had demonstrated to be worthy of [I’m guessing he is talking about bosses]. He says that he would follow them anywhere.

My observations:

• I like the communication channel metaphor, it shows that it’s really hard to communicate our brains contents, because our interfaces are so limited.
• Knowledge can be increased brain-internally, by deriving new facts from old ones. I wonder how much that matters.