The business impact of code quality (2017)
arxiv-export1.library.cornell.edu
arxiv-export1.library.cornell.edu
Note: this paper was written by an employee of Codescene, the tool used in the paper to analyze code quality.
A codebase that is brittle - meaning things break easily, testing is low, or where maintenance or new dev is difficult - is a genuine business problem. The solution to that is engineering managers that can make a persuasive case to non-technical people for why something needs to be done a different way, or failing that, will black box that entirely and add the needed maintenance to an existing business initiative. Put another way, play corporate politics like regular politics and tack what you need onto a bill that must pass. Showing an executive a report from code analysis tool is unlikely to work.
But as a founder and an active software engineer, far too often "technical debt" is used by programmers to advanced their personal preferences, which may not be aligned with the businesses in any way. A few highlights of things I've been told are technical debt in recent years: not using micro-services (when we had no need for the added complexity or scaling features), using promises instead of observables (in a non RX codebase), using a mono repo (again, zero business problems caused), using any number of 3rd party libraries (vs the developers desire to build from scratch), using Github instead of GitLab (or the reverse), etc...
And debt is a really un-useful term for this, too, IMHO. More often than not, when you're down the line and dealing with the concequences of prior shortcuts the optimal solution you can think of now is different to the one you considered at the time of the original decision. And it also completely ignores the concept of great, perhaps also expensive, decisions taken in the past that are now no longer such a good fit. They weren't knowingly done as a debt, but the world changed.
The word "debt" has too much associated meaning. People understand the term too well. Instead I'd like people to just talk about "change" instead. Value judgements about the reasons we got here don't add anything useful to the decision on the tradeoff as to whether the suggested change is worth doing.
Many reasons and excuses for each, but the first one is usually due to business reasons (why polish and mature one feature when you can develop five) while the second is due to engineering reasons.
Again, as you say, I think the solution is simply to develop trust with the stakeholders to whom you're trying to sell the ideas. Technical leads - in a unique position of understanding the costs and the benefits - must be vigilant to bat away the spurious claims that certain topics (such as those you mention) require addressing, as trust lost is difficult to recoup.
At an engineering company management up to the board should all be engineers.
Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer.
> But as a founder and an active software engineer, far too often "technical debt" is used by programmers to advanced their personal preferences, which may not be aligned with the businesses in any way.
That's often a comp problem. Are your engineer's incentives aligned with the company (via stock options for instance)? If not, it's probably better for them to refactor your product to use whatever tech is pushed by the place they want to jump ship to (for a better comp package of course).
> using a mono repo (again, zero business problems caused)
Mono repos have a lot of advantages (most notably that it makes cross-component changes atomic). There's a reason Google adopted that model.
> using any number of 3rd party libraries (vs the developers desire to build from scratch)
Keep in mind there's a hidden cost to any third party dependency, especially if you have to modify it but your patches won't make it upstream.
> Then, these conversations become much easier, since things that break (and a pattern of repeated failures for the same thing) should be obvious to any real engineer.
This is a fallacy that I often observe in engineers. We believe that our work is the one that brings value and all decisions should be made by people that do what we do. We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them). Opportunity costs for example: We could pay down this tech debt, but what else could we do with the same money. We all love shining codebases over everything else, because it makes our work easier. But finance folks have other priorities - and balancing those priorities is one of the core tasks that management has. Placing only tech folks in management is unlikely to produce balanced results.
And yet it does. At least, at tech companies.
> We also believe, that non-tech folks cannot understand what we try to explain. I also very often observe that many engineers have no idea of basic concepts that are required to run a business (and often, no interest to learn about them).
That's a very good point. However, my observation over the years is that great engineers can pick up business concepts (it's often a requirement to graduate anyways) but non-technical managers can't generally master engineering to the same degree.
I still think we need better ways of properly measuring this "brittleness". And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt. Often these things are so vague that it really just comes down to a 1-vs-1 between the manager (who wants the feature out now) and the engineer (who may have been drinking too much microservices kool-aid). "I could have built this faster if we had switched to React last year" ok but roughly how much faster? Better measurements can make these discussions more objective, just like how scientific studies and data analysis are used in real politics.
Of course we can't ignore the glaring issue with this paper specifically and it's relationship with Codescene, but I do wish to see more studies in this direction.
Indeed. Perhaps spending 42% of time overcoming tech debt is steady-state, and paying the debt down shrinks the pie (i.e. customer base).
It is an act of balance.
We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.
We already try to measure these things with Agile and sprints. It's not perfect but many would argue it's better than zero estimation at all. However often the focus on sprints leaves long term investments like code quality out of consideration. More studies and data can provide better information on when these trade offs are worth it.
Imagine if a large scale study came out that said companys that migrated to microservices ended up spending on average 2 additional months on migration if they delayed the migration by a year. Certainly this would be useful information for other companies thinking about the same.
HN is strewn with stories of people with dependencies on log4j, left-pad, and who knows what else. A programmer wanting to move off log4j and build logging from scratch might seem like a personal preference for some time, until the entire tech staff suddenly has to go into lockdown to remove dependencies on a dependency like log4j.
It can vary one way or the other, but if I advocate for not using a 3rd party library there is usually a good reason.
Outside of very large software companies, developers add business value by writing things that don't already exist. Spending time rewriting third-party libraries has dubious business value.
The risk of third party libraries is that they often do far more than needed for an individual project. Log4j got into trouble with a feature that supported remote lookups over LDAP.
That's how it starts. Then you need to log to file. Then you need to rotate those files. Then someone asks for a custom format. Eventually you end up with a crappy internal Log4J clone.
Feels like the opposite?
Precisely. A useful way to think of technical debt is that it should be a tool that is intentionally used to navigate the tension between cost now vs. later, for some benefit (usually quicker delivery).
If code is poorly written inadvertently (e.g. lack of experience, poor programming skills, carelessness, etc.) that is a different kind of burden on those working in the codebase.
"This research was initiated to make code quality a business concern by putting numbers on the impact of low-quality code. We chose this line of research since code quality has been an abstract concept that rarely gets adequate attention at the management level"
As a software manager, of course, I know Code Quality is important as it is at the core of maintaining a business software in the long run, especially when you have multiple teams and are hiring new engineers.
The thing is, IMO, even when you have code quality as a value in your team, you will have different opinions about which code quality standards are you going to have and some groups don't feel ok whatever the decision is.
Here is a Ruby tool that gives you a similar report: https://github.com/chad/turbulence
And a Python one: https://github.com/danuker/lookout/tree/nohardcode