Joshua Herzig-Marx

Every few months, I re-read Tom DeMarco’s book Slack. It’s a brilliantly rationalist book arguing that maximizing the busyness of individual knowledge workers minimizes the effectiveness and productivity of the organization as a whole.

This concept is promoted by Eliyahu Goldratt and his Theory of Constraints and in his books like The Goal. He argued that in in the case of discrete manufacturing–where individual goods are produced in a continual but not continuous process through the discrete application of heterogeneous transformations–as the utilization (or efficiency) of the individual steps approaches their maximum, the productivity (or throughput) of the system as a whole approaches a minimum. Now, software development looks to me a lot like discrete manufacturing. You have a set of inputs of varying quality: requirements, best practice documents, etc. In a factory, the machines that perform a step in the manufacturing process often differ – they could be different models, have different maintenance histories, have different tolerances with regards to inputs or throughput, or produce at different levels of quality. Tom DeMarco reminds us that knowledge workers–and this includes the analysts, designers, developers, and engineers–are similarly not fungible. Not only does each individual have their own specialties and deficits but people have task switching costs analogous to the set up costs with factory machines.

While Slack was the first book I read to apply TOC methodologies to software development, I’ve been noticing that it’s not an uncommon perspective. The Agile Management Blog is thick with these ideas as is Steve Hebert’s Development Blog, the Creative Generalist, and Frank Patrick’s Focused Performance Weblog.

Using the TOC approach provides two primary advantages:

1. The opportunity to apply an empirical science to the fuzzy art of software development management–and a science tested in modern manufacturing industry.
2. A concrete and tested method for examining, evaluating, understanding and improving your development processes

As the name implies, a central tenet of TOC is the identification of your system’s primary constraint. Often called the bottleneck, this the step in your system that controls the maximum throughput, and systemic throughput, according to TOC, is the most important metric of effectiveness. As the constraint control the throughput of a system, no increase in resource utilization outside the constraint will increase systemic throughput. The only option, then, is to increase utilization of the constraint itself.

In the software world, the constraint could be code review by the lead architect. It could be sign off by legal. It could be client feedback. It could be any number of things. However, once the constraint is identified there are a limited number of available actions:

1. Add capacity to the bottleneck. Typically this means increasing the number of people who can perform the bottleneck task(s).
2. Ensure the bottleneck only does high quality work–improve the quality of its inputs. Before the architectural code review, code could be peer reviewed. The legal department could prepare guidelines or an inexpensive paralegal. Internal client surrogates could be used.

Remember, though, that these changes can possibly move the bottleneck. Code review is fine but QA is stalled. Client feedback is coming in fast and furious but issues are no longer being adequately prioritized. Moreover, resources cannot be added indiscriminately–there’s still a cost to task switching and adding resources to an already late project typically only increases the delay.

That’s enough out-loud thought for me. Something to think about – what limits your organization’s productivity? And what can you learn from other disciplines?