Simplify Essential Complexity; Diminish Accidental Complexity

 Simplify Essential Complexity; Diminish Accidental Complexity

Neal Ford

ESSEnTiAl CoMplExiTy REpRESEnTS the difficulty inherent in any prob- lem. For example, coordinating a nation’s air traffic is an inherently complex problem. Every plane’s exact position (including altitude), speed, direction, and destination must be tracked in real time to prevent mid-air and runway collisions. The flight schedules of aircraft must be managed to avoid airport congestion in a continuously changing environment—a severe change in weather throws the entire schedule out of whack.
Conversely, accidental complexity grows from the things we feel we must build to mitigate essential complexity. The antiquated air traffic control system used today is an example of accidental complexity. It was designed to address the essential complexity of controlling the traffic of thousands of airplanes, but the solution itself introduces its own complexity. In fact, the air traffic control system used today is so complex that updating it has proven difficult, if not impossible. In much of the world, air traffic is guided by technology that is more than 30 years old.
Many frameworks and vendor “solutions” are the symptoms of the accidental complexity disease. Frameworks that solve specific problems are useful. Over- engineered frameworks add more complexity than they relieve.
Developers are drawn to complexity like moths to a flame—frequently with the same result. Puzzle solving is fun, and developers are problem solvers.

Who doesn’t like the rush of solving some incredibly complex problem? In large-scale software, though, removing accidental complexity while retaining the solution to the essential complexity is challenging.
How do you do this? Prefer frameworks derived from working code rather than ones cast down from ivory towers. Look at the percentage of code you have in a solution that directly addresses the business problem versus code that merely services the boundary between the application and the users. Cast a wary eye on vendor-driven solutions. They may not be inherently bad, but vendors often push accidental complexity. Make sure that the solution fits the problem.
It’s the duty of the architect to solve the problems inherent in essential com- plexity without introducing accidental complexity.
Neal Ford is a software architect and meme wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is the designer/developer of applications, instructional materials, magazine articles, courseware, and video/DVD presentations, and he is author and/or editor of five books. He also speaks at lots of conferences. You can assuage your ravenous curiosity about Neal at http://www.nealford.com.