“I would not give a fig for the simplicity on this side of complexity, but I would give my life for the simplicity on the other side of complexity” – Oliver Wendell Holmes.
When our commercial reach exceeds our technical grasp; when the systems we develop become too complex to understand, then we must either stop to remove complexity, or run the risk of loss. A system can be so simple there are obviously no errors, or so complex there are no obvious errors.
Complexity propagates downstream in a system’s life cycle, exponentially increasing the time and cost of system development, testing, regulating, marketing, selling, operating, and training.
For a variety of organizational and personal reasons, it is much, much harder to remove complexity than add it. To quote Albert Einstein, “Any intelligent fool can make things bigger and more complex. It takes a touch of genius – and a lot of courage – to move in the opposite direction.”
The single most valuable thing system engineers can do for their organizations is facilitate the transformation from simplistic to complex to simplified through the selective, judicious, expedited, coordinated, and informed application of sound, data-driven system engineering practices such as concept engineering trade studies, set-based concurrent engineering, modeling and simulation, retrospective data analysis, interactive data visualization, and prospective, well-designed experiments.
I don’t believe engineers are adding complexity out of malice, or for fun, or to satisfy their egos or curiosity. Instead, there are two factors driving the increase in complexity: governance and capabilities.
Governance: There are a host of external factors (making the quarter, cost-plus contracting, sunk-cost fallacy, HiPPOs or Highest Paid Person’s Opinion, Sinclair’s Law) which compress schedules, constrain simplification efforts, or encourage complexity, thereby preventing engineers from removing complexity.
Capabilities: Many engineers lack the experience or skills to remove complexity. It can take decades of progressive increases in responsibility for an engineer to amass the experience necessary to cope with the unique challenges of a large, complex, software-intensive sociotechnical system. Do you really want your engineers “learning on the job” with your most complex, highest-stakes systems?
The ultimate lair of complexity is software (as embodied in firmware, control algorithms, IT, databases, computer models, and simulations). Software is creating new system safety challenges, as explained by Nancy Leveson in her new book Engineering a Safer World. As a simple example, I have been doing some “recreational” software development to analyze data coming from my son’s insulin pump and continuous glucose monitor. I wound up with all sorts of junk in my program—nonfunctional/dead-end/testing code—the byproducts of development. If I hadn’t taken the time to clean it up, I would now be carrying a “technical debt” forward, putting my son at risk.
A super-complex system is the hallmark of inexperienced engineers in an inexperienced organization. Pursuit of simplicity is not simple. A simple system belies the complexity of thought that went into its development.
It takes upfront time, effort, practice, intelligence, and skill to simplify. Organizations must be willing to accept the short term costs of removing complexity. Pay now or pay later.
Lane Desborough is a product strategist with Medtronic.