Simplify essential complexity; diminish accidental complexity
From Softarch 97Things
Essential complexity represents the difficulty inherent in any problem. 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 sever 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 it’s own complexity. In fact, the air traffic control system used today is so complex that updating it has proven to be 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 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 vs. 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 complexity without introducing accidental complexity. By Neal Ford This work is licensed under a Creative Commons Attribution 3 (wc 342)
Exported (poorly) from http://97-things.near-time.net