Technical debt isn't technical by Einar Høst

For more info on the next Devoxx UK event 👉 www.devoxx.co.uk
Technical debt is not primarily caused by incompetent developers, architecture astronauts, unrealistic UX people or even stupid project managers. What causes it then? It is a symptom of weak abstractions, which stems from insufficient understanding and modelling of the problem domain. These inadequacies are compounded by organizational inertia and communication problems. This means that we cannot hope to address our so-called technical debt by virtuous coding alone. In order to avoid technical bankruptcy, we must step away from the keyboard and start addressing the complex mess of human issues that ultimately affect the software we are making.

[@DF-ss5ep]

Very smart talk

[@fennecbesixdouze1794]

The story reinforces that the biggest problems in the software industry are simply power dynamics. No software engineer would have ever thought that "it must be easy to reuse code for the new horse". The problem here is simply that the "product owner" in the story was not a software engineer. They thought that because a donkey is similar to a horse, that there must be lots of "code reuse" potential available to them. Of course, that could have been true, but only if the product owner were a software engineer, an expert at domain modeling, and capable of separating generic high-level functionality from low-level functionality. Only if they knew how to start by scoping out simple, generic features based on general properties, and keep deeply isolated any highly specific low-level code. If the product owner were technical, then they would have understood it is not that simple to generalize code. Instead, because the product owner was a technical idiot, and because the product owner was allowed to set the business priorities instead of the software engineers, the product owner asked for very specific and detailed functionality that depends strongly on the deep specifics of horseness. The only solution here is for technical businesses to become more technical. Company CEO's should be themselves software engineers. "Product" people should be picked out out of software engineering departments. The technical development team should be given a larger impact on the organization's key strategy and direction, and all deference should be given to technical people. All other companies will simply fail, it's a waste of time to even try with them.

[@fennecbesixdouze1794]

To follow-up on this: you are likely working in a company where the CEO has never worked as a software engineer, your product designers have no technical competencies, and your leadership does not prioritize technical concerns. This is because we have only begun the technical transformation. As technology advances, the technical transformation of industries will only accelerate and the traditional modes of operation will be subsumed. Your company may be profitable for now, but it will fall soon. Eventually a company that is driven by technical concerns will take over your industry, either a company founded as a technical company (e.g. Amazon), or a company that has transformed from a traditional company into technical ones (e.g. IKEA, Disney, Nike, Walmart etc). If you are say a Walgreens, with Amazon Pharmacy looming over you and Walmart's digital transformation looming over you, you had better bet you are either looking to digitally transform very quickly, or die.

[@ph.m.8091]

You have titled this: Technical debt is technically not technical 😁