The Challenge of Managing Complexity
Software complexity grows faster than our ability to manage it. Businesses get more complex, so the software supporting them follows. Languages and tooling improve, but the underlying problem remains: every system eventually becomes harder to change than to replace.
The Complexity Cycle
Engineers try to manage complexity through diagrams, architecture documents, and visual representations. It helps for a while. Then the system outgrows the diagrams. A new team is brought in to redesign from scratch, and the cycle repeats.
Economic Pressure Makes It Worse
During growth periods, companies hire more people to manage their software. When budgets tighten and headcount drops, those same systems become unmanageable overnight. The complexity didn’t change – the capacity to handle it did.
The only durable fix is reducing complexity itself, not adding more people to manage it.
Why Simplicity Is Hard to Sell
Simplicity sounds good in theory. In practice, it faces resistance. Complex systems justify larger teams, more meetings, more planning sessions, and more billable hours. A simple design can look “not challenging enough” in a peer review.
Engineers have a love-hate relationship with complexity. We complain about other people’s complexity while being drawn to creating our own.
Open-Source Software: The Biggest Lever
OSS is the single largest factor in reducing the code we have to write. Without it, most of what we build today would cost an order of magnitude more in time and money. OSS lets us stand on existing work and focus on business problems instead of reinventing infrastructure.
Where OSS Falls Short
OSS solves common problems well. It does not solve your specific business problems. Most successful open-source projects are either generic tooling or serve a popular niche. They give you the platform, but you still write all the business logic and domain-specific interfaces. That part doesn’t get simpler with better tooling – it gets more complex as the business grows.
Match Complexity to the Problem
Developers keep adding layers to the development process: more abstractions, more tooling, more infrastructure. Companies start viewing software development as too expensive. But most of that cost is self-inflicted.
Not every application needs microservices. Not every product needs AI. Not every startup needs the same operational sophistication as a FAANG company. Many applications need well-designed interfaces, solid architecture, and smooth workflows – nothing more.
Match the complexity of your solution to the complexity of your problem. Use OSS where it fits. Skip what you don’t need. The cheapest code to maintain is the code you never wrote.
What to Do About It
- Use OSS for infrastructure, write only business logic. Every line of custom infrastructure code is a liability.
- Refactor regularly. Complexity compounds. Small, continuous simplification beats periodic rewrites.
- Reward simplicity. If your culture treats complex designs as impressive, you’ll get complex designs. Incentivize the opposite.
- Build for your actual scale. Not the scale you hope for in three years. You can add sophistication later; removing it is much harder.
- Default to “just enough.” The risk of over-engineering exceeds the risk of under-engineering for most projects.
- Align stakeholders on scope. Developers, management, and clients need to agree on what complexity is justified. Misalignment here is where bloat starts.
If you’d like to discuss software architecture or complexity management, reach out at aleksandar@nesovic.dev or via nesovic.dev .