Codrin Băleanu remembers the one time when his Boeing flight experienced a system failure. The pilots executed a forced landing, a scary moment for all passengers. In the moment, Codrin decided to buckle down, lay back and trust the captain. There was one more thing that gave him reassurance: the complexity of the planes.

“I knew there were redundant subsystems that can act as a backup when something fails,” recalls Levi9’s engineering lead. “In this case, complexity saved lives.” But in software, the story is quite different. In the tugging war between complexity and simplicity, where should developers land?

A necessary evil

“Complexity is a phenomenon that occurs in nature,” says Engineering Lead Alin Costea. “Even the simplest hydrogen atom, with a single proton and an electron, can form space clouds, nebulae, and stars.” The natural emergence of complexity from simple elements is similar to what occurs in software systems. “It always starts with something simple,” but you quickly end up with a BPM Workflow with multiple distributed systems and many additional services.

Mobile Tech Lead Tiberiu Grădinariu calls complexity “a necessary evil, which is inevitable in the life of a project.” Any complex project needs more effort to develop and to understand, so the speed of development is slower. However, he notes that this complexity often brings unexpected benefits: “It’s an opportunity for people in the project to learn.”

The Stockholm syndrome of complicated

Codrin says that complexity can become problematic when it captures people into believing that things should always be complicated. “Worse, they feel proud about it,” echoes Alin. “I have seen presentations with diagrams that look like a tangled mess, making your head hurt and the team was proud of how many connections and microservices were represented.”.

For Tiberiu, complexity can become harmful when it’s left unchecked. “We have to always fight against it, controlling it and pushing towards order.”

What’s left when you take everything out

While complexity might have saved his life, Codrin aspires to simplicity and inserts this quote at the end of his every email: “Simplicity is a great virtue, but it requires hard work to achieve it,” by pioneering computer scientist Edsger Wybe Dijkstra. His definition of simplicity, inspired by Antoine de Saint-Exupéry, is “everything that’s left when there is nothing left to take out.” In software development, Codrin prefers to have one thing that does something well and then connect all the different pieces together. “Simplicity is the ultimate sophistication,” believes Alin.

Is your code a bazaar or a cathedral?

Current software development deals with complexity in two different ways. One can be compared with building a cathedral – a monolithic architecture, harmoniously planned and executed. While looking elegant, the construction relies on very few people who have the knowledge of how it was built and how it can be repaired when it fails. “If you need a software architect to debug something, it’s already too complicated,” points out Tiberiu.

The other, more modern, is a bazaar-like approach. “When we need to cook something, the first step is to go to the market and buy the ingredients. We do not begin with planting tomatoes,” points out Codrin. Modern software uses integrations, public libraries, employs existing tools, and makes use of existing available services. While this development approach looks more chaotic and complex, it has a lesser chance of failing. “In an open source system, where you have hundreds of thousands of people using them, bugs are shallow.”

“The fastest code you can write is no code at all,” adds Alin, emphasizing a key current software development concept. This concept encourages developers to simplify as much as possible and to consider if new code is needed when current solutions may work.

The smallest step

To embed simplicity in their work, developer teams should sometimes get up from the discussion table where the whole workflow is thoughtfully planned and simply identify the smallest viable solution to the problem. “Make it work, make it right, make it fast, in this order,” Codrin quotes the hacker ethos, advocating a pragmatic approach to development that promotes functionality above optimization.

However, enterprise and startup approaches to complexity differ greatly. “In enterprise projects, you know from the start that it needs to be maintained for many years,” Tiberiu says. “It doesn’t make sense to implement the first solution that comes to mind, because you’ll definitely need to refactor it later.”

“Sometimes you know from the start that things will be complex and you can’t make them simpler than they need to be,” Alin reflects. The key is to discern between vital complexity that serves a goal and accidental complications that don’t provide value.

The price of simplicity

Simplicity frequently costs. “When you’ve abstracted something, you’ve lost the detailed picture,” Alin says. “You no longer know exactly what’s happening there; you just know that it happens.” In this case, complexity is simply delegated, points out Tiberiu. Modern software developers struggle with this simplicity-transparency trade-off.

The conclusion is that simplicity and complexity aren’t mutually exclusive. It’s about finding the proper balance for each situation. The most important question, according to Codrin, is “What’s the simplest thing that could possibly work?”.

This method embraces complexity when it’s necessary. Whether using microservices, third-party technologies, or creating from scratch, the goal should be to give value while keeping systems simple—but not too simple.