[ManWith2Plans]

I absolutely agree with the first part of this advice.

As to the assertion that complexity is not worth worrying about, I could not disagree more. I have watched projects fail time after time because of complexity, dependencies, and lack of budget.

Managers should encourage their engineers to spend time trying to simplify architecture and reduce code, infrastructure, and package dependencies. Smart engineers can learn to think simply over time, but this will not happen automatically. (I plead guilty to gravitating toward complexity in the early part of my career, but I have since learned better.)

Managers should place emphasis on using existing patterns wherever possible rather than re-inventing the wheel. Practicing laser focus on delivering value, evaluating solution dependencies with an eye to keeping things simple, and accurately modeling the problem domain in question.

Rather than trying to fight with engineers about implementation approaches, managers should try to guide engineers toward arriving at these conclusions themselves. I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.

[ubercore]

> I have also found that stressing simplicity as a key performance metric for engineers is a useful tool.

Some of the smartest engineers I've ever worked with produce code that is so well crafted it feels simple when you look at it, but it's actually extremely clever.

I think the conversation about "clever", "smart", "volatile" programmers tends to align the axis of _code_ complexity with cleverness, but often the cleverness is in finding the perfect simple solution.

[agentultra]

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." -- Edsger W. Djikstra

Complexity sells better because it's cheaper. This is not the, "look at this novel abstraction I wrote and proof of its correctness with respect to our specifications," kind of "complexity" that folks often mean. It's the hand-waving, just add the simplest patch you can to make it work for the business problem at hand, type of complexity. The kind of complexity that ends up with giant balls of "really simple" code that nobody understands entirely anymore.

It sells better for all the usual reasons that driving slightly over the speed limit gets you where you're going a little faster. It's only a problem if you get caught or cause a collision.

[eternalban]

Your comment touches on the awol concept of clarity in this conversation: "The quality of being coherent and intelligible".

Balls of mud are the very essence of simplicity (in one sense) yet lacking any clarity.

Clarity is a (bad sort of) hot commodity in an immature yet rapidly developing technical field. In our field this is exacerbated by the fact that the entire field can be viewed as a monument to the peter principle (but thankfully the imposter syndrome is there as a collective salve for us all.)

I think highly intelligent engineers that can penetrate the essence of a problem and come up with effective & coherent conceptual models are a valuable but (in places) untimely assets. My recommendation to such engineers (who also wish to be responsible team members) is to recognize the cognitive impedance mismatch and broaden the 'scope' of the solution to include the human element, and descend to norm if necessary. The ultimate goal is to serve a broader goal, and fighting against impedance mismatch is un-/counter-productive.

My personal red line is the 'big ball of mud' teams.