The Importance of Dependencies

The fundamental question in any project always comes down to “What is going to be delivered, and when?” Arriving at the truest answer to this question is the holy grail of all collaborative building projects. Imagine a conversation with a few tradespersons building a home:

“Charlie, When will those two boards be nailed together?”

“Two minutes (assuming the hammer hits the nail on the head and the boards stay true).”

“Ana, when will this wall be framed?”

“Three hours (assuming the studs were nailed together as planned (assuming the hammer hits the nail on the head and the boards stay true)).”

“Jack, when will the house be framed?”

“5 days (assuming the walls were framed as planned (assuming the studs were nailed together as planned (assuming the hammer hits the nail on the head and the boards stay true))).”

At each level, the “what” that is being delivered changes. Everyone along the chain of delivery asks for their “what.” And sometimes, when they worry, they ask for the “whats” before that, and before those:

“Are you sure the frame will be done in 5 days, Ana? What about the kitchen wall, Jack? Will Ana really get it in time?”

Depending on the level you look, not only does the answer but the question changes as well. At the micro level, we are asking “When will those two boards be nailed together?” One level higher: “When will this wall be framed?” Another level: “When will the house be framed?” until finally: “When can we move in?”

At each higher level, the answer becomes loaded down with more and more assumptions.

So, the answer is always, “it depends,” meaning, it is critical that at any level it is easy to unroll those dependencies to both calculate and justify the answer.

Sometimes the “what” is more important than the “when,” such as we often see in the video game industry, or with Apple hardware releases, where rumors of and actual delays are the norm.

Sometimes the “when” takes primacy, especially in emerging software startups, where Minimum Viable Product is the goal, and first customers have the expectation that they will be beta users for a long time.

Sometimes neither matters, as in the world of experimentation and research into emerging or not-yet-existing markets, such as Alphabet’s X – the moonshot factory.

Both “what” and “when” are important in large projects with many interdependencies and cross-team collaboration, where delays and bugs can have significant cascading upstream and downstream effects as you might see in the enterprise software industry and high-technology-equipment manufacturing.

Planning and executing the delivery of software is the art of minimizing that cost, which means identifying, classifying, and minimizing risk throughout the life cycle by correctly identifying and tracking dependencies.

Building the Assembly Line

Now a thought exercise to draw a (literal) picture of what the Codex means in practice: we will build a saltshaker.

In the physical world, the order of operations is largely obvious, thanks to gravity. In order to build up, you must root down. No roof can be placed on a home without walls. No walls can be placed on soil without a foundation. While some things can be built in parallel, and stitched together all at once, the full assemblage can never exist out of order.

So to make these dependencies obvious, let us start with an example in the physical world. Consider the saltshaker. A ubiquitous, unassuming resident of every kitchen and restaurant table. What is it made of?

Simply:

A base that holds salt, and a lid with holes in it.

Let us break that down a bit more.

The base is hollow. It is light enough to be picked up with one hand. It may be transparent, allowing one to see how much salt is inside. It may have ridges, or texture to ensure a secure grip while shaking. The top is threaded to secure a removable lid. The base is flat, to keep it upright. It has enough volume to store many shakes of salt. The lid has holes in it, of just the right diameter to let some grains pass when inverted, but not too many. And there are enough of these holes that every shake accumulates enough salt to mitigate the need for too many shakes when seasoning a typical plate.

As the inventive humans we are, we imagine the construction of this saltshaker. We invent it backward by detailing its physical components in their final form:

The base is a hollow cylinder of ridged glass, threaded at the top. The lid is stainless steel, perforated on top, and threaded to the size of the base.

And imagine backward thus:

The lid: Given a steel disc, shape it into a lid. Thread the lid and poke holes in the lid.

The base: Given glass, shape it into a hollow cylinder. Thread the glass at the top of the cylinder.

Assembly: Screw the lid onto the base.

It is helpful now to draw the nouns of the process described above as they change through time (Figure 11-1).

And connect them with the verbs (Figure 11-2).

And now we have our simplified assembly line.

Our verbs are actions being performed on the nouns. Actions require tools, so let us make that explicit (Figure 11-3).

Every tool takes a certain amount of time to do its work – to transform the object from one state to another. And some states take a tool longer to transform than others. In our case, it turns out that threading a glass cylinder takes two minutes, while threading a steel disc takes three.

Let us next indicate how long each step takes via the length of the line (Figure 11-4).

Threading and perforating of our lid could happen in either order, so we have a second option for this assembly line where we flip the order of those two steps (Figure 11-5).

Based on this, how long does it take to build our saltshaker?

The obvious answer is eight: the longest cumulative line. This cumulative line is our calendar time. And it turns out, making the lid takes longer than making the base. The lid is our gating factor . In fact, our cylinder is waiting for one minute before the lid is ready to be assembled to it (Figure 11-6).

Pretty simple and straightforward so far, right? Now let us complicate it.

It turns out our factory can only afford one threader and one shaper! What this means is that we can neither shape nor thread two different parts simultaneously. Figure 11-7 shows the overlap in our original assembly scenarios where the same tool would be in simultaneous use.

Now that we have our assembly line, and this new constraint where the same tool cannot be used simultaneously, how can we parallelize the work to minimize the calendar time spent (indicated by the length left to right)?

Now play out each possible scenario (removing the final assembly step which is common to each).

Figure 11-8 depicts the first scenario, where we thread the lid before perforating it, and delay using the shaper for the cylinder one minute so the lid can use it first. The calendar time (length of the longest set of lines, left to right) is 6, effort time (total time tools are in use) is 11, and idle time (the amount of time a tool is not available for a task which uses it) is 1.

In the second scenario (Figure 11-9), still threading the lid before perforating, we instead choose to delay the use of the shaper tool on the lid, which causes us to also need to delay the use of the threader tool while the cylinder finishes using it. The calendar time in this scenario is 10, effort time is still 11, and idle time is 9. The cylinder assembly line sits idle for a whopping 5 minutes while the lid is completed.

In the third scenario (Figure 11-10), we switch the order of threading and perforating of the lid, which removes 1 minute of idle time from Scenario 2 as we no longer have simultaneous need to use the threader on each line. This reduces our calendar time to 9, effort time is the same at 11, and idle time reduces by 2, as not only do we not need to wait for the threader tool on the cylinder line, but we also finish a minute earlier, so the cylinder line waits less time before it can start again on the next saltshaker.

In the fourth scenario (Figure 11-11), we shape the disc first (as in Scenario 1). Now the threader is operating on the lid after the perforator, so the lid waits on the cylinder assembly to finish with the threader before it can be threaded. Finally, the cylinder waits for the lid to complete. This scenario has no change to calendar time, effort time, or idle time compared with Scenario 3.

Scenario 1 has the fewest gaps, or least idle time possible, at 1, and also has the shortest calendar time, at 6. Scenario 1 is the optimal choice.

In Review

Once we identified the possible dependency trees, we were able to play out scenarios until finding the optimal solution.

This same mechanistic process of optimizing the assembly applies just as well to our software assembly line. As with our saltshaker, all software delivery methodologies are dependent upon how well the end product can be envisioned and broken into discrete, sized, and sequenced tasks, which are then optimally parallelized across shared resources.

If anything causes the tree to change, we can simply reconstruct the new tree and replay scenarios as above, choose the optimal one, and resequence our assembly line to reflect it.

In this book we will move this saltshaker analogy into the software world, making the case for the effectiveness and feasibility of this platonic ideal, and how we can best approach it in a variety of circumstances. Because it turns out that doing this well, in the right way, not only maximizes certainty around what will be delivered by when, it also minimizes the cost of the inevitable: change.