Engineers complain about technical/technology debt (“tech debt”) but often feel powerless to fix it and labour painfully through it instead. However, the stack is growing, so how do you manage to keep it in check? Technology debt can only get solved once you stop seeing it as a technology-engineering challenge and start addressing it as an operational-cultural change.
This three-part series goes deeper into the cultural challenges of tech debt and seeks to offer new perspectives and solutions to finally cure it.
Is tech debt a plague?
In many organisations, tech debt is rampant, like a plague. First is the historical debt made of a combined mesh of engineering and architecture debts accumulated over the years, even decades. Next, there is the debt that is still leaking every sprint.
For example, as Gene Kim explained in a past conference, every time software is put live without automating tests, release, and deployment; it is tech debt leakage. Also, when you work from some engineering principles you cannot put into practice, e.g. refactoring code as part of building out new functionality, any time you do not correct what you were supposed to, debt is leaking. Although some leakage is always likely to a degree, it shouldn’t be left to build up. At least you should repay an equivalent amount continuously.
Tech debt also manifests through spaghetti code. I remember a team taking on a terrible application in a bank: a highly critical one and a mess of spaghetti. Every change that should reasonably have taken hours was taking days or weeks. It took many months for team members to develop confidence in not breaking something catastrophically. What a waste! When engineers spend more time understanding what they are likely to damage than what they are building, you know you are in trouble.
The farcical Definition of Done (“DoD”)
Every time I walk in such an environment, I ask if there is a definition of done (“DoD”). Some senior engineers will point me to Confluence. Other team-level engineer responses will vary:
- Definition of what?
- It just needs to pass the tests, right?
- Yes, we have documented something, but nobody applies it.
- It is too long and impossible to use it. We don’t have the time.
Dual standards
So, there is no DoD, then?! A standard does not exist because it is published. It is only a standard if it is effectively adopted. So, what are you doing for adoption? The effort is not for more elaboration of a longer list to perfect code. It is for working out a level of application in practice.
Another senior engineer will proudly show a static code analysis software that reports on all those vulnerabilities and smells, often in the thousands. It even calculates the “debt” and the effort to fix it. So, do you have a plan to address all of those?
Then comes the excuse that some smells are not that problematic and should not be fully accounted for. How do people know what to follow and what not? How can you bend over the standards? It should not be part of the pass criteria if it is unimportant. If it is relevant, it should be stopped and fixed if it is flagged as a defect. A standard cannot be a dual standard.
The challenge of seeing the quality in software work
In my experience with digital work, quality is invariably challenged because software is virtual. Nobody sees the software, yet everybody takes it for granted that it is clean.
Additionally, quality is often the only flex. Expectations are set, deadlines are looming, egos are sometimes on the line, and when the impossible pressure mounts, the only possible choice is to cut the corners that nobody sees.
Engineers do not like it. Every engineer I have met takes pride in their work, and to put it frankly, compromising the quality frustrates them greatly!
Yet, engineers are equally their worst enemy. Because they aim to be helpful and responsive, they go along with the music and prioritise functionality over quality. Over time, it normalises in the work system. People work that way, junior engineers grow that way, and the deadline and cutting it through testing are all that matters. Quality is second to it. It is a worry for another day. But that other day never seems to come.
The damage of working on projects
A project set-up reinforces the dysfunction:
- The deadline is all-important; the rest never registers on the same scale.
- The power imbalance does not offer possibilities to challenge authority.
- A big bang delivery requires intensive testing once, which inevitably compromises automation. The same goes for releasing the software.
- As the team’s tenure on a project is ephemeral, the ownership of the resulting debt will be somebody else’s problem. The debt gets boxed up for the support teams.
- The more the project will run as a “death march”, the worse it will be (the term death-march projects indicates situations where senior people are unwilling to compromise on unrealistic expectations and ask/coerce/force teams to put in heroic efforts, working unhealthy hours such as late nights and weekends, for a project to meet its – often artificial – deadline).
Since organisations are still very much run from projects (because they are much more convenient to model from a cost-accounting perspective), the debt is perennial and only grows. A product-based organisation addresses many of the above downsides, yet it is hard for the leadership to give up the convenience of project-based budgeting.
Leadership of quality
The challenge of quality in digital is so entangled that it is often at a deadlock. As a result, many digital businesses (or the digital eCommerce and online services of traditional companies) are on very shaky foundations.
Answering it is sketchy, with much hand gesticulation and the inevitable view that you need better engineers and have no time. You have the engineers you can attract, so you’ll have to work with them. Most of the time, anyhow, with some training, application and discipline, said engineers would perform adequately. Whenever you think you have a people problem, you effectively have a leadership challenge. Quality needs to find attention within the constraints of your business and with your people. That’s where to start.
Leadership is about anticipation, and, in the case of quality, it is about not letting something spiral out of control. Digital quality only becomes a visible problem when it is way too late. Releasing updates and new features takes much longer, stability becomes poor, teams are continually disrupted, and agility is only ever a pipedream, no matter how much Scrum you will do.
So, as senior engineers, how do you put quality on the radar of business decisions? In my next instalment of tech debt as the plague of digital businesses that don’t go away, I’ll discuss the key principles of quality and how quality is everybody’s role, not just the engineers’.
Philippe Guenet is the founder of Henko, the performance coach in digital business. Philippe is nearing 30 years of experience in digital and coaches businesses and technology leaders in realigning businesses to their Flow and better leadership.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more!