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
be.
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 reviews.
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 design. 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.
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 costs, 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.
Conclusion
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.
Frank Neff
