This is the second in a series of posts about Lean principles and software architecture by Nanette Brown. Read the first post, Lean Principles and Software Architecture: Categories of Waste.

In Lean production, “waiting refers to the periods of inactivity in a downstream process that occur because an upstream activity does not deliver on time. Idle downstream resources are then often used in activities that either don’t add value or result in overproduction.” 1

The “waste of waiting” is certainly applicable to software development. Developers waiting for architecture specifications to be produced may be underutilized or may begin development anyway, potentially producing throwaway code or, more likely, making the “official architecture” moot. Developers waiting for requirements will often be pressured to start coding and therefore may feel obliged to make their own best guesses about what the customer wants. Testers may be idle waiting for a code drop, followed by an intense, exhausting blitz once the code finally does arrive.

If waiting causes waste, then why do we do it? Few of us wait due to laziness or lack of desire to accomplish the task. In many cases waiting is an inherent outcome of development processes that incorporate large batch sizes in the pursuit of efficiency. (I will discuss this more in an upcoming post on the “waste of inventory”)

For architects, the waste of waiting is an important aspect of the economics of architecture decision making.

Traditional waterfall development environments place a heavy emphasis on avoiding the waste of defects and the waste of rework. Phase gates are established and evidence is extensively compiled and evaluated to ensure that architectural decisions are made once, are made right, and are not revisited. In other words, the process encourages architects and development teams to wait until they’ve got it right before proceeding.

A Lean perspective on architectural decision making incorporates consideration of the “cost of delay” and the “cost of buying information” into the decision-making calculus.2 As long as the impact of an architectural defect is not life threatening, in certain circumstances the cost of rework that results from getting a decision wrong may be lower than the cost of delay (in revenue or user value) incurred by waiting to ensure that the decision is 100% correct. Similarly, waiting and investing time and money to “discover” requirements that do not in fact exist is clearly a waste in situations where requirements emerge and change in response to market forces or in response to users’ experience of the system itself. In such cases, it will be cheaper to “buy” information in the form of user feedback than to invest in detailed analysis of user needs.

This is not to say that delaying an architecture decision while gathering further data is never a good idea. On the contrary, it is often the most prudent and economical use of time and resources. But sometimes the waste created by waiting outweighs the benefits. The choice is not a matter or right or wrong and should not be a matter of compliance or non-compliance to process mandates. It’s a matter of economics.