Why complexity in software projects is bad (and you should not advertise it)

There are (still) many people telling proudly, how complex their product is. There are job ads, explaining that you will “create highly complex software”. These false signals, which I personally saw in many positions and projects, create a potentially huge long-tail problem, not primarily for engineers, but for the product management and engineering team lead. In this blogpost, I want to point out some of those impacts of advertising complexity…

Complexity of Business Process

When building digital products, it turned out as a good practice to categorize complexity in categories. The first, I call it “complexity of business process” describes how complex the process behind your product is. So for example, a simple camera app (press button, take photo, show photo) is not very complex, but a full-blown CRM probably is. If the requirements or even simpler, the process you want to digitalize is complex, the software you’re building will always be1.

Of course it’s becoming worse, if the business process is broken or not well defined. Then the software made of it will probably be broken or at least buggy.

Keep in mind: If you digitalize a not well-defined or not well working process, you just move its complexity and problems into code, where you can’t observe it anymore.

Intrinsic Complexity

My second category covers “self-made” complexity during an engineering process. There are various reasons for intrinsic complexity, e.g.:

  • Changing requirements
  • Technical debt (historic technical problems, which lead to problems in current development)
  • Lack of Knowledge (an engineer didn’t knew a simpler solution)
  • “Superheroism” (an engineer wanted to make it more complex then needed for personal/egoistic reasons)

Intrinsic complexity can be prevented to a certain extent by actively promoting knowledge and establishing a working development process with quality assurance mechanisms like static code analysis and peer reviews2.

Impacts on the Product

When it comes to the practical impact, the kind of complexity is not relevant anymore. It doesn not make a difference, if the business process is badly designed, the requirements are unclear, or the quality of the product was not assured from the beginning. All those different kinds of complexity (or “problems” they become), have the same impacts on the product:

Bad User Experience (UX)

To the user, the application feels unintuitive, difficult to handle, or even not usable. These problems often arise due to poorly designed processes in the application or insufficient UX design3. Of course, there is no standard solution for these problems. However, it often helps enormously to staff the roles in the project (especially business analyst, UX engineer and UI / frontend designer) strongly. Especially in projects with smaller budgets these roles often overlap, but it is crucial that they are defined and staffed.

In most of the projects I’ve seen fail so far, these roles were not or insufficiently staffed. Don’t skip proper business analysis or UX engineering because of low budget.

Bad Performance

Since performance is a separate discipline in software development, it cannot be generalized in any case. Also, the reasons for poor performance can be almost anything. However, one reason for this, which I myself have observed many times, is the complexity of the application itself.

In theoretical computer science, complexity always means time. Simple things are fast, complicated things take a long time. Since process complexity cannot always be prevented, performance becomes a constant companion.

You can significantly reduce the impact of this problem category by introducing and further developing quality assurance measures (static code analysis, automated tests, load tests, etc.). If performance is a critical factor, and it often is, use technical tools to continuously measure and analyze performance.

High Ongoing Costs

This is a purely logical conclusion, because complexity always causes additional costs4, but also simply an effect of the previous problems. Poor performance causes higher hosting expenses, confused users more support cases.

Even in the rare case that you don’t care if your software is slow and barely unusable, it will cause high costs in hosting and support, which will increase with time and further development.


Complexity, also from a business perspective, is always bad. Try to avoid or minimize it, not only because it fosters a poor development culture and morale, but also because it can result in very high, ongoing costs. Last but not least, complexity always means effort and frustration, which you can lower for everyone involved, by taking business analysis, development processes, and quality assurance seriously.

You May Also Like

How a Strong Type System Saves You Documentation, Tests, and Nerves

How a Strong Type System Saves You Documentation, Tests, and Nerves

I was recently inspired to finally write this post. Especially in weakly- or untyped languages, such as the JavaScript or PHP world, the added value of strict type systems is often not recognized. Instead, many discussions and comments revolve around the need for tests or code comments. Contrary to that, in the functional programming world, we leave such checks to the compiler. In this post I would like to give a short overview and explain how to use a strict type system for everyday checks instead of writing type checks, tests and documentation for it.

How to effectively visualize an Application Landscape in Enterprise Architecture

How to effectively visualize an Application Landscape in Enterprise Architecture

In enterprise & solution architecture, connecting boxes with arrows is an often used and overrated visualization from high-level, thru component architecture, down to data and class diagrams. However, to create a holistic view on systems, component diagrams are not enough! When it comes to analysis or transformation of a high-level application- or service-architecture, I prefer to draw an Application Landscape Diagram, which I would like to show and elaborate on in this post.