200 OK SwatantrAI

97 Things Every Software Architect Should Know – 2/97

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.

97 Things Every Software Architect Should Know – 1/97

As engineers we sometimes recommend technologies, methodologies and approaches for solving problems because deep down we want to have these on our resume and not because they are the best solution for the problem. Such decisions very rarely result in happy outcomes.

The best thing for your career is a long string of happy customers eager to recommend you because you did the right thing by them and for the project. This goodwill will serve you orders of magnitude better than the latest shiny object in the latest shiny language or the latest shiny paradigm. While it is important, even critical, to stay abreast of the latest trends and technologies this should never happen at the cost of the customer. It‘s important to remember that you have a fiduciary duty. As an architect you have been entrusted with the well-being of your organization and its expected that you will avoid all conflicts of interest and give the organization your undivided loyalty. If the project isn’t cutting edge or challenging enough for your current career needs then find one that is.

If you can’t do that and you are forced to be in such a project, then you and everyone else will be happier using the right technology for the customer rather than for your resume. It‘s often difficult to resist utilizing a solution that is new and cool, even when it‘s inappropriate for the current situation.

With the right solution, the project will have a happier team, a happier customer and overall far less stress. This will often give you time to go deeper into the existing older technology or to learn the new stuff on your own time. Or to go take that painting class you always wanted to do. Your family will love you for it, too – they’ll notice the difference when you get home.

Overall always put the customer’s long-term needs ahead of your own short term needs and you won’t go wrong.