Structure in the design of systems is usually represented by some form of schematic or block diagram.  Block diagrams describe logical relationships between design elements, without getting hung up on physical detail.  UML class diagrams and electronic schematics are examples of such abstract structural models of “things that are made out of things.”

Graph diagrams have one big trick for managing scale by collapsing compositional hierarchy into subdiagrams.  Most of the time, I don’t care how an integrated circuit works, I’m only interested in the inputs and outputs.  I’d rather treat it as a unified thing, even if the components on the inside of the thing are of the same type as the components I connect to the outside.

If our biggest scaling trick is reserved for object composition, then other hierarchical relationships may be described by color, symbolism, or layout.  Color can be tricky because of problems with reproduction and perception (colorblindness is common).  Symbolism works well for simple type relationships, but it’s difficult to represent taxonomy with nothing but icons.  Edge layout is the first and most expressive tool of block diagramming, but layout quickly runs into problems with scale.  Block diagrams are not the panacea of design modeling.

Large diagrams can become incomprehensible as they scale beyond a few 10′s of nodes. Most block-diagram notations allow an ad-hoc layout. Imposing rules upon the layout of the diagram can preserve comprehension and communicate additional information about structure. Resistance to orderly layout is itself useful information about structure.

There are some wonderful algorithmic graph layout tools that we can apply to help us make sense of things, but there are also a few simple manual layout tricks we can apply to finding latent structural patterns. It’s useful to know a few tricks for discovering structure when you are given a set of entities, but you don’t yet understand the relationships between them. It’s even more useful if these tricks can be applied at a whiteboard or in a spreadsheet without the need for expensive and/or complicated software tools.

Radial layouts equalize the significance of nodes and emphasize patterns between edges. They also scale up nicely.  These can be very useful for discovering relationship patterns in a system that is new to you.  You can make a pretty big circular diagram on a whiteboard with sticky notes for nodes and ink for edges.

Linear layouts are easy to draw.

They scale up decently, equalize nodes, and emphasize patterns between edges. They can optionally encode sequence along the node axis, but they don’t have to, and we’ll see why not encoding sequence is also useful.

Linear layouts are especially useful when we make a rule about the direction of the edges.

Any leftward edge that we can’t remove by reordering the nodes is a dependency cycle. Generally, you want to avoid such cycles in your design structure.  A useful consequence of such a linear layout is that it can easily be translated into a matrix of relationships between diagram nodes. The reason becomes more apparent when you orient the graph along a diagonal axis:

The graph

can be represented as the matrix

Such an adjacency matrix can be referred to as a design structure matrix, or dependency structure matrix.  The tabular form of a design structure matrix makes it a useful tool for understanding the relationships of large interconnected systems.  A block diagram with 26 nodes may be simple, or it may be visually unwieldy. The equivalent DSM always has the same layout:

With our matrix form, we can apply simple row and column reordering to maximize the number of edges on one side of the diagonal.  The dependency matrix of a decoupled design can be made to have all of its edges under the diagonal.   Any edges above the diagonal that can’t be removed by row/col reordering are dependency cycles.

In a coming article, we will expand on this matrix technique to further understand and manage the structure of large systems. We may also discover something in the patterns of relationships that will help us to manage the work of building and maintaining such systems.

In the last two posts, we’ve discussed some useful properties of internal workflow queues:

• queue states between processes can provide an early warning of process breakdowns
• local work-in-process limits serve to slow down a malfunctioning workflow and free up resources to fix it
• queues can sometimes be combined to reduce the total work-in-process while still preserving their buffering function

I gave an example of workflow throttling, and suggested there was another configuration of those internal queues that could respond more smoothly and gracefully than the simple, independent queues given in the example.

In order to pull a work item, there has to be a place to pull it from, and there should be some way to distinguish work that is eligible to be pulled from work that is still in process. At the same time, there has to be a place to put completed work when you are done with it. A completion queue serves both these functions.

In this case, we can have up to 3 items in the “specify” state AND we can have up to 3 items waiting for the next state in the workflow. The team can pull new work into “specify” whenever there are fewer than 3 work items in process. If there are already 3 work items in process then the team will have to wait until something is moved into the completion queue. If there is some kind of blockage downstream, first the completion queue will fill up, THEN the specify queue will fill up, THEN the specify process will stall. And when it stalls, it stalls all at once. The flow is either on or off, there’s no middle speed, and it keeps going until it stalls.

In another example, we still have a busy state and a complete state, but the token limit is shared between them. In this case, we can have 4 items in process OR 4 waiting. Or we can have (3 busy + 1 waiting) OR (1 busy + 3 waiting).

In the ideal case of 3 busy and 1 waiting, this queue works just like the first example does. However, if work starts to accumulate in the “complete” state, then the “specify” state will incrementally throttle down. The effective WIP limit for “specify” goes from 4->3->2->1->0 as more items are completed ahead of the rate of downstream intake. So, the process slows before it stops, and it slows much sooner than it would have under the independent queues.

What’s more, even though it operates in the same way in the normal case, it does it with two fewer kanban in the system. Fewer kanban, with gradual throttling and smoother flow, should result in lower lead times.

With this in mind, let’s reconsider our scenario from the previous topic:

	1. Something is going wrong in the design process, but nobody knows it yet.
	2. The specify-complete queue starts to back up, thereby throttling down the WIP limit for specify. A resource is freed as a result, who should now inquire into the cause of the backup, which may only be random variation. The code process continues to complete work and pull from the existing backlog.
	3. Code state begins to starve and specify state throttles down another level. Two more people are released as a result. There’s more than enough free resources now to either fix the problem or shut down the process.
	4. The stall completes by flushing out the specify and code states.

It still takes a while for the system to stall completely. The difference is that it begins stalling immediately, and when it does stall, it stalls with less WIP. For equivalent throughput, this pipeline should operate with fewer kanban and less variation in WIP, and therefore should have smoother flow and shorter lead times. It should respond faster to problems and free up resources earlier to correct those problems.

These shared completion queues might be the most common type of workflow queue. There are a couple of other types that we use, and we’ll take a look at those in a future post.

Kanban directly addresses the lean values of pull and flow, but only indirectly addresses the values of value and perfection. It would be useful if our workflow directly spoke to those values, so that we might form a complete process that fully embodies lean principles. There is some tension between value and perfection, so we will need some discipline and understanding in order to bring that tension to a harmonious resolution. As it turns out, there is a product development methodology that is deeply concerned with these values: Design for Six Sigma (DFSS).

I think it’s important to remind ourselves from time to time that we’re interested in lean because we’re interested in pull, value, and perfection, and not vice-versa. If you don’t need these things, if “pretty good and pretty soon” are good enough for you, then there’s no need to fuss with all of this lean business, and craft methods will probably suffice. But if you find yourself in a situation where:

• You have direct competition in a market.
• The consequences of operational failure or poor quality are great.
• You have a large user population.

…then you may need a little more than “pretty good and pretty soon.”

What is Six Sigma?

The title question might appear a little opaque at first, but we can break it down. To begin with, what is Six Sigma and why would you want to design for it? Taken literally, Six Sigma refers to a goal of limiting the frequency of production of defects, defined in terms of variation from a product specification. If you take a closer look at the components of Six Sigma and ask what the purposes or consequences of those components are, you might come away with a more practical definition:

A set of principles, practices, and tools for the systematic improvement of business processes.

Putting things in more neutral cause-and-effect terms helps us to reason about them more objectively. Then you can decide how you feel about systematic improvement of business process, independent of any particular terminology. If you decide that process improvement has value to you, then you may look into the matter and discover that Six Sigma offers one point of view on that topic, as do Lean, Theory of Constraints, and others. Further, most of these systems have some shared history within the field of quality and process control. If you view each of them as a collection of ideas, connected by themes, then you may find a particular combination of those ideas that speaks most clearly to your particular situation. In fact, the cross-pollination of these systems has been a hot topic in recent times.

What is Design for Six Sigma?

In its original form, Six Sigma is oriented towards repetitive processes like manufacturing. Further, it’s oriented towards improving processes that already exist. But if the underlying design of a product or its process is sufficiently flawed, then it may not be possible to “improve” our way to quality. It is better to “design quality in”. Perhaps we can design the product in such a way that it does not need so much improvement in production.

To the end of designing-in quality, a companion methodology was developed, called Design for Six Sigma, or DFSS. The goal of DFSS is the economical development of high-value, high-quality product designs. Like its complement, DFSS is a collection of theories and practices that work together in service of that end.

The components of DFSS each have long and illustrious histories in industry in their own right. They include:

• Quality Function Deployment: A theory of customer value. Practices for discovery of customer value, analysis of competition, priority of product features.
• Theory of Inventive Problem Solving (TRIZ): A theory of technology evolution. Practices for the systematic discovery of high-value design problems and their solutions.
• Pugh Concept Methods: We don’t want the first design we think of, we want the best design we think of, and we want options.
• Failure Modeling (FMEA): Practices for discovering what’s likely to happen outside of your carefully controlled development environment.
• Design of Experiment: Design notations like source code describe what we want the system to do. Now what does it really do?
• Taguchi Robust Design: The real world is noisy and unpredictable. Robust systems work well in spite of this.

and perhaps most importantly:

• Axiomatic Design: A rigorous theory of design structure. Practices for evaluating design quality and decomposing design structure.

Some versions of DFSS include Axiomatic Design and some don’t. For those that do, Axiomatic Design is the conceptual glue that binds all of the other pieces together (like the Force). For those that don’t, QFD plays that role.

I wouldn’t be me if I weren’t disdainful of tribes, hype, and comprehensive branded methodology frameworks. Nonetheless, the way that the DFSS practices complement one another is remarkable. Understanding how they complement each other also illuminates how to fit each practice into your own process. Is there any value in “doing DFSS”? No. Is there value in designing robust products? Yes.

How does Design for Six Sigma relate to software development?

DFSS does not have much to say about writing code. Neither does it have much to say about drawing circuit schematics or mechanical drawings. This is because DFSS is about systems engineering and product design, independent of any particular technological domain. Any system that can be decomposed into parts and is subject to economic calculation in its development is within the scope of the methods of DFSS.

This has some interesting consequences, not the least of which is that it puts software development on an equal footing with other engineering disciplines within the context of product development. You do not want to hear: The Boeing 787 is a marvel of modern engineering…except for these 6.5 million lines of code, which were merely ‘developed’. DFSS relates all design decisions to all other design decisions, and holds them all to the same quality criteria, regardless of how they are notated or which mathematics they use.

The questions that DFSS addresses are fundamental to software development: quality, value, reliability, robustness. DFSS, by its nature, offers the best thinking on these subjects. If software developers have not caught up with this yet, it is because currently popular software development methodology is deficient. But this idea is catching on. Jayaswal and Patton’s Design for Trustworthy Software is exactly about DFSS for software development, and I think there will be more books to come on this subject.

How does Design for Six Sigma relate to Lean?

The intersection of Lean and DFSS is the state of the art in product development. Part of the importance of Axiomatic Design to DFSS is exactly that it provides a theory for incremental, iterative, and evolutionary design. Suh’s Independence Axiom shows that the best designs for evolutionary development are simply the best designs. Conversely, any design that would be considered ideal could have been constructed by an evolutionary process. That is, the criteria for design ideality and evolution are one and the same.

Suh’s design axioms apply directly to software systems. They unify all other DFSS methods, and they unite DFSS with lean development and evolutionary design. The intersection of Lean Thinking, DFSS, and Software Engineering is coming, and it is very exciting! Perhaps we might call it Robust Evolutionary Design.

On the other hand, my own journey down the road of lean development started with Donald Reinertsen’s Managing the Design Factory. Don’s description of Lean Product Development is more like the application of lean production principles to product development, breaking the work into small pieces, managing capacity, measuring flow, and delivering value incrementally. It is this view of lean that my friend David Anderson expounded upon in his book Agile Management for Software Engineering.

The difference between TDS and TPS creates a lot of confusion in discussions about Lean Product Development. Does LPD mean product development targeted to lean production systems? Or does it mean the principles of lean production applied to product development? These two definitions have very different consequences.

If it wasn’t already clear, I am decidedly in the camp of lean production principles applied to product development workflows. Even though I think TDS is ingenious, and I wholeheartedly endorse set-based thinking, I do not consider TDS to be Lean Product Development. To me, lean development is a means to an end. That end is evolutionary design, and lean production fits that end in a way that set-based development does not. Which is not to say that there is not a strong evolutionary interpretation of SBD, as large-scale open source development is exactly that. But I’m not really speaking to the open source audience here. I expect my readers are largely of the enterprise variety, building products or IT systems to spec and for hire. And evolution with such finite resources means flow.

Observant readers have probably noticed that I don’t talk much about Mary and Tom Poppendieck here. I feel a little bit bad about that, because I think they deserve credit and respect. I think they have done the software profession a tremendous service by popularizing the relevance of lean principles to software development. But they have also done a couple of things that bother me, including blurring the definition between set-based, time-boxed methods like TDS and continuous workflow methods like TPS. The consequence of this is that people can (and do) weasel out of lean principles by hiding behind the weakest interpretation. By conflating these definitions, the Poppendiecks, perhaps unwittingly, encourage their readers to claim to be lean while avoiding actually doing it. One of the greatest offenses I see again and again is the rationalization of “craftsmanship” under the auspices of Lean.

In contrast, Womack and Jones (and Roos) were not at all ambiguous about what is Lean and what is not. Jim Womack, who coined the expression, “lean production,” to describe the principles behind the Toyota Production System, explicitly defined lean production as neither craft production nor mass production. Not craft production is part of the definition of lean, and he dedicates whole chapters in his books to why craft production is inferior:

Our advice to any company practising “craftsmanship” of this sort in any manufacturing activity, automotive or otherwise, is simple and emphatic: Stamp it out.
- The Machine that Changed the World, The Strange Case of the “Craft” Producers

Now, I realize that development is not manufacturing. But using that as an excuse to rationalize craft methods is overwhelmingly contrary to philosophy of lean. I am not saying that you shouldn’t practice craft development if that’s what you want to do. But claiming that it is lean to do so is either ignorant or outrageously dishonest. Standard Work is not an optional practice. Craftsmanship means doing it your way, Standard Work means doing it our way. If you’re not doing Standard Work, you’re not doing Lean. Period.

The system performs function A.

Software engineering:

The system performs function A under operating conditions B with operational performance parameters C with tolerances within the probability distribution D and reliability within the probability distribution E and we are legally responsible if it doesn’t.

As you can probably imagine, one of these problems is harder than the other. My interest is in explaining why it is still possible and even desirable to address the second problem with evolutionary design.

Agile methods can explain how to manage evolutionary design for the first problem. They have so little to say about the second problem that they almost appear to deny its existence. Software engineering methods are largely concerned with the second problem, but they usually apply a simple-minded mass production mentality to management. I guess “serious” software engineering researchers haven’t considered management to be a sufficiently interesting problem.

Maybe I’m a dreamer. I want both. In fact, I don’t think Software Engineering can be made to work without evolution. The best that a phase-gate system can hope to offer is to solve yesterday’s problem (i.e. the wrong problem) with great precision. I want the optimum solution to today’s problem, today.

Class invariants and contracts are not about testing. They are about reliability. The purpose of a class invariant is to minimize the state space of the system, both at design time and at run time. A class invariant is an extension to your type system. You will get the most power from them if you think about them and use them in that way. I love dynamic languages, but the people who bitch the most about type systems probably don’t understand how to use them correctly. The compiler is your friend. Static analysis is your friend. Class invariants make types smarter.

Reliable systems fail at the earliest opportunity. Sounds counterintuitive?

The loom stopped instantly if any one of the warp or weft threads broke. Because a device that could distinguish between normal and abnormal conditions was built into the machine, defective products were not produced.

- Taiichi Ohno

If we can divide requirements into small and similarly-sized pieces, then one-piece flow and continuous improvement are possible.

Our conclusion is that both analysis and evidence show that it is possible. So the next question should be: under what conditions is it possible? This leads us to question the premise:

Under what conditions can we divide requirements into small and similarly-sized pieces?

In my mind, that is really the fundamental question of iterative product development. In order to address that question, we’re going to have to talk about design. Clarifying our understanding of the nature of design will lead us to discover what we need to know about the process of design.

1. The user need/customer requirement/voice of the customer is paramount to the success or failure of the product
2. All facets of a business need to be involved in (and interact with) the design core in parallel and not sequentially
3. To satisfy the user need, rigorous systematic working is required throughout the design core using modern methods
4. A product’s status needs to be assessed accurately before starting any new design
5. Within systematic working, a cyclical process of synthesis/analysis/synthesis is necessary, brought to a satisfactory conclusion by the appropriate methods
6. The most up-to-date elements of engineering, based on sound engineering principles, must be used as appropriate
7. Total design teams must be multi-disciplinary, with sufficient expertise within the team, and sufficient diversity of experience
8. Consideration must be given to a wide range of alternatives without prior commitment to any particular alternative
9. The design team must repeatedly scrutinize and test the information and reasoning on which a design is based
10. People performance is critical to total design performance
11. Engineering principles are a vital subset of total design; they influence but do not necessarily relate directly to the user need
12. To minimize the cycle time for completion of the design core (to minimize process losses), systematic working with modern methods and aids is required
13. Total product quality is only achievable through total design

I know of no popular software development methodology that lives up to these ideals. So, we are trying to define one!

MINIMIZE COUPLING, MAXIMIZE COHESION

…laser etched onto his or her corneas. Software engineering rightly concerns itself with these two properties as the primary considerations of structural design. And it turns out that proper attention to these things is necessary to the effective operation of lean scheduling.

The definitions of cohesion and coupling are interrelated, so that it is a bit difficult to tease one out in isolation, but a simple definition might be:

Cohesion measures the semantic strength of relationships between components within a functional unit

Coupling measures the strength of all relationships between functional units

Cohesion is closely bound to the idea of abstraction. An information system is ultimately composed of physical devices, themselves layers of abstraction, that are assigned logical meanings and are built up into progressively more abstract constructs in order to finally represent human intentions. There are different styles of abstraction, from the functional, to the relational, to the object-oriented, but they’re all after the same goals of modularity, composability, and hierarchy.

Of the two properties, coupling is easier to measure and understand, because it is more mechanical in nature and requires less interpretation. Suppose there are three components A, B, and C. A’s behavior depends upon B in some way (any way), A’s behavior depends upon C in some way, and the behavior of B and C do not appear to depend upon anything else. That’s pretty much it, that’s the coupling of the system according to our definition, and it’s the sort of thing that a machine can figure out by simple measurement.

Cohesion is more difficult to measure directly because it is a measure of the meaning of relationships, and not just their mechanical strength. However, cohesion has a very strong influence on coupling, and systems that feature poor cohesion often feature poor coupling as a consequence. We usually discover poor cohesion when we are looking for the cause of poor coupling, or through casual inspection, because designs with poor cohesion tend to look like gibberish. A machine would have to understand the intention of the designer in order to measure cohesion effectively. I don’t know about you, but I find some comfort in the fact that machines don’t have that capability yet.

So, we can take all of this to heart and build a system that would appear to have low coupling and high cohesion. All of the modules represent clear abstractions with inviolable abstract data types. All variables and tables have clear types with equally clear labels. All functions perform the one and only operation that their identifiers suggest that they do. There is no global state of any kind. Further, modules communicate with one another in such a way that not only avoids dependency cycles, but forms a perfect tree, the very ideal of low coupling.

Can we thus characterize our system as having low coupling and high cohesion? The answer is: it depends.

But…we followed the rules, how can I say that it depends? The answer is: it depends on how the system is used. The system may have a beautiful internal logic, perfect in its self-consistency, but if the semantics of the system are inconsistent with how the system is used in practice, then it may actually exhibit very strong coupling.

Let’s examine why. It turns out that the classic computer science definition of coupling may be insufficient because the definition of cohesion doesn’t necessarily relate the structure of the problem domain to the structure of the solution domain. If there is a direct correspondence between the functional requirements of the system and the design structure of the system, then our original design preserves its status of minimum coupling. If there is no interaction between the functions themselves, then we say that the system is functionally uncoupled.

Still with me? I promise that this is of the utmost relevance to lean project scheduling!

A functional requirement of the system may have dependencies upon multiple design elements. Common dependencies mean that functions have an opportunity to interfere with one another, either at design time or at run time. However, this interference can always be resolved by applying the functions in a certain order. If the system functions can always be resolved by sequencing, then we would say that the system was decoupled. The dependency graph of the functions of the system contains no cycles. Purely uncoupled designs are uncommon, so most workable designs in the world are of the decoupled variety.

By adding only one more design dependency, we have now added a nasty dependency cycle between functions 2 and 3. Because each function shares the same common dependencies on the design structure, there is no way to avoid interference between them. This interference may manifest at design time or run time, but probably both.

What this case means is that a design has been applied to a problem for which it is poorly suited. The design has good internal structure, but because it is poorly adapted to its purpose, it will perform poorly. This design would satisfy the classic software definition of low coupling and high cohesion, but it’s still a badly coupled design.

The importance of functional coupling to lean scheduling is about rework and variation in task duration. A design that contains functional dependencies will necessarily cause retesting and rework as old design decisions must be revisited to accommodate new dependencies. Keeping the functional dependency graph acyclic makes this manageable because the refactoring required to complete any particular new functional requirement can be completed in a time that is a function of the number of shared dependencies. Refactoring of requirements with cyclic dependencies may require more extensive rework and possibly architectural re-engineering.

The lean way to deal with this, of course, is to make satisfaction of global coupling criteria part of the completion of any particular new function, and to allocate a portion of engineering capacity to continuously optimize total system structure. This is essentially the same approach as the agile practices of continuous integration and refactoring, but we can have criteria that are a little bit more precise than “bad smells.”

Some functional coupling is due to factors that are beyond the direct control of the designer. This often involves shared system resources that you can’t change. In these cases, the design may not be amenable to refactoring, and requires the installation of a decoupling device. Decouplers in software systems usually take the form of semaphores, message queues, virtual memory, processor schedulers, and the like. They make a shared resource appear to be dedicated to each client, usually according to some kind of time slicing. It is helpful to see them as a more general example of decouplers, because this perspective makes other design alternatives more apparent.

As it turns out, Extreme Programming addresses the issue of functional coupling, in its typically blurry way, with the idea of Metaphor. The use of metaphor improves the chances that the design will be well suited to its intended function. Further, the practice of regular refactoring ensures that the cohesion of the design remains high, and that the integrity of the metaphor is subject to continuing scrutiny. Feature Driven Development also addresses this issue by construction of a domain model and use of object-oriented design techniques to align the structures of the problem and solution domains. In the right hands, FDD or XP practices are likely to keep a design within the decoupled realm, although in an informal manner. Metaphor is a convenient mechanism for managing this issue, but we don’t have to settle for XP’s hand-waving explanation, because we can have the real thing. There is a neat mathematical description of functional coupling relationships and we will get into more detail about that in a future post.

It is nice that one can simply follow these methods and know that they will produce a good result, but it also nice to know why they work and how to measure the results. Our goal of elevating agile development methods to the level of Software Engineering requires that we do so. A more rigorous definition of coupling also helps us find hidden interactions that we never intended. Because at the end of the day, source code can only describe what we want the system to do, and not what the system actually does.