“Where do I find the documentation for that?”, I asked the sales engineer on the other end of the line.

“It’s on page 673”, he replied confidently.

His fellow team members were quite impressed by the display of organizational expertise. I, on the other hand, was wondering why the hell this company had a 1,000 page long document explaining how to integrate with their service.

As soon as the call ended I turned to my co-workers and suggested that we find a different vendor.

Complicated By Design

The vendor in question, who will remain unnamed, appeared to follow the defining law of “enterprise software”: make it complicated by design.

Complexity for many means job security.

Have you seen how many people are required to implement and maintain a Salesforce instance? It’s too many.

The reason for this is that in contrast to basic products, which aim to do one thing really well, enterprise software is expected to encompass all business logic and edge cases of any organization.

Granted, it’s not the world’s worst idea but the outcome is that such products are by their nature, worse than the laser-focused “best of breed” alternatives.

Intentionally or not, a product team can head down the path of building “enterprise software” with a single phrase: “You know what would be a cool idea?!”

This phrase, whether it comes from a prospective customer or an internal employee, is the source of much evil.

Don’t get me wrong, I love a good brainstorm. However most perceived “great ideas” are enmeshed in the promise of transformation. In other words, “If you do X, it will change the trajectory of Y! All thanks to me!”

If a team is small or the originator influential, this promise is often sufficient to force the idea into, what Andrew Chen calls, the product death cycle. Death by a thousand cuts, or in this case, features.

An Explosion Of Ideas

As a human who becomes bored without sufficient distraction, I regularly seek out new projects. This happens both at home and at work.

In other words, I’m frequently the source of that evil phrase, “You know what would be a cool idea?!?”

Yet when I become buried in projects, I suddenly recognize the path forward. Should I not take this path, I’ll end in a situation similar to Sylvia Plath:

I saw my life branching out before me like the green fig tree in the story. From the tip of every branch, like a fat purple fig, a wonderful future beckoned and winked.

One fig was a husband and a happy home and children, and another fig was a famous poet and another fig was a brilliant professor, and another fig was Ee Gee, the amazing editor, and another fig was Europe and Africa and South America, and another fig was Constantin and Socrates and Attila and a pack of other lovers with queer names and offbeat professions, and another fig was an Olympic lady crew champion, and beyond and above these figs were many more figs I couldn’t quite make out.

I saw myself sitting in the crotch of this fig tree, starving to death, just because I couldn’t make up my mind which of the figs I would choose. I wanted each and every one of them, but choosing one meant losing all the rest, and, as I sat there, unable to decide, the figs began to wrinkle and go black, and, one by one, they plopped to the ground at my feet.

For Sylvia, she describes a life filled with too many ideas and dreams. This can just as easily represent an aimless organization, buried under the weight of countless incomplete projects.

It was all of those great ideas that set us off in a thousand directions. Yet now the time has arrived to judiciously narrow our focus.

Time To Strip Things Bare

It’s not merely life or projects that become encumbered by complexity. All poorly engineered solutions are by their nature far too complex.

Nassim Taleb, author of Antifragile, would correctly argue that such complexity is a source of fragility. In apophatic theology, growth is gained “via negativa”, the negative way. In order to become anti-fragile, and decrease all downside, we must implement addition through subtraction.

Taleb exhaustively covers this concept in his book but his take on how we learn is most illustrative:

[I]n practice it is the negative that’s used by the pros, those selected by evolution: chess grandmasters usually win by not losing; people become rich by not going bust (particularly when others do); religions are mostly about interdicts; the learning of life is about what to avoid. You reduce most of your personal risks of accident thanks to a small number of measures.

The same thing goes for product design. When we remove all unnecessary features, functionality, and complexity, what exists is something that just works.

Antoine de Saint Exupéry, a French writer, poet and aviator, effectively articulates this in his analysis of the design of airplanes:

Have you looked at a modern airplane? Have you followed from year to year the evolution of its lines? Have you ever thought, not only about the airplane but about whatever man builds, that all of man’s industrial efforts, all his computations and calculations, all the nights spent over working draughts and blueprints, invariably culminate in the production of a thing whose sole and guiding principle is the ultimate principle of simplicity?

It is as if there were a natural law which ordained that to achieve this end, to refine the curve of a piece of furniture, or a ship’s keel, or the fuselage of an airplane, until gradually it partakes of the elementary purity of the curve of a human breast or shoulder, there must be the experimentation of several generations of craftsmen. In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness.

Nothing > Something

So where’s the code?! Code is what manifested all those “cool ideas” from earlier into reality.

The code, supported by aspirational and motivated teams, unintentionally set the trap. Yes, the business is still around and operating at scale.

However growing complexity is quietly lurking in the dark. We must stay vigilant against it! We must ask ourselves not what we can add to make our projects and code better but instead what we can remove.