It is week 3 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 2 continues building the case for checklists to deal with complex and complicated environments. This chapter firmly pins down the idea that checklists save time, money and lives. (more…)

It is week 2 of our re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along). Chapter 1 builds the case that the world we live in and the work that we do is very complex.  Complexity creates the possibility for errors, and checklists are a tool to help avoid error in complicated and complex environments. (more…)

Do many hands make a task more complicated or more complex?

Do many hands make a task more complicated or more complex?

I am often asked about difference between complicated and complex. The two terms are often conflated, confused or generally used incorrectly, which in software development and maintenance can lead to erratic results.

Complicated systems have a predictable outcomes based on their initial state; based on the initial state you will be able to predict where you will end.  A simple definition of complicated, from a systems perspective, would be ‘lots of steps in the process.’   The puzzle’s initial state is the picture on box.  The process of assembling the puzzle must end in a single deterministic state, unless your dog eats one or more of the pieces.

The outcome of a complex system is impacted by the initial state and by interaction with outside forces.  A simple definition of complex form a systems would be ‘lots of different inputs that can change the direction of processing.’  A 5,000-piece puzzle is complicated. Unlike the puzzle, weather is complex. Weather as overall system is affected not only by its beginning state (the original picture in the puzzle example) but interactions with the terrain, atmospheric heating and hundreds of other factors that continually change based on inputs from other systems and interact with the weather.

Bringing the two concepts closer to a typical development project, let’s say that we have a pile of several thousand Legos and a picture of the StarShip Enterprise.  The picture represents the user requirements, the Lego bricks are a metaphor for the software code. If a single developer was asked to build the model of the Starship Enterprise from the pile of Legos®, we would describe the project as complicated.  Alternately if asked five developers to each build a part of the Starship Enterprise that would fit together at the end using the same pile of Legos, we would be describing a complex project.

When developing systems, understanding the difference between the two concepts is important. Why? Because managing complexity and complicated requires different techniques, tools and possibly frameworks. For example, quality of complicated projects will improved by techniques like code reviews, unit integration and regression testing that helps team members focus on the detail and to ensure that initial state links to the needed end state.  In the Lego example, the developer is using these unit level techniques to compare what he is assembling to picture on the box and to make sure they match.

Complex problems require more than just a focus on the detail. Software development programs are complex by definition.  Programs represent multiple teams at varying degrees of autonomy attempting to construct the solution to a large business problem.  In the United States, is an example of a complex software development program that went awry.  The complexity requires teams to use other techniques or risk bad surprises.  For example, using the Agile techniques of short iterations and continuous integration provide feedback mechanisms. The Agile feedback mechanisms provide guidance for reducing risk from from overarching concepts like architecture that that are generally decided early in a project. These techniques also deliver information on how the components will interact as they are assembled.  Using our Lego example, if every ten minutes all of the team compared what they had built to the picture and then tried to fit them all together they would have a better chance at managing the complexity in the process in order to deliver a completed model that met the requirements.

Big projects with lots of teams scream complexity, therefore must leverage tools, techniques and frameworks that provide the feedback needed keep the project on track.  Putting a picture of the StarShip Enterprise on the wall for the single builder to use as reference is adequate to help guide a complicated project, but will be less valuable when 10 builders are creating parts that will need to fit together at the end.  Understanding the difference between the concepts of complexity and complicated helps project teams to select the right tools for the right job and the helps the process improvement teams to craft the right tools for the tool box.