In IT, there is a paradox when it comes to job titles. Somewhere along the way, the practice of linking job titles to a candidate’s (desired) experience became established in large parts of the market. This then created the now famous and omnipresent job titles like “Senior Software Engineer”, “Professional DevOps Engineer”, etc. In this blog post, I would like to explain the paradox around these designations and how I use them in the course of the talent search…
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.
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.
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.
S. F. Ochoa and F. J. Gutierrez, “Architecting E-Coaching Systems: A First Step for Dealing with Their Intrinsic Design Complexity,” in Computer, vol. 51, no. 3, pp. 16-23, March 2018, doi: 10.1109/MC.2018.1731079. ↩︎