4 ms·

> Code quality remains an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for time

> Code quality remains an abstract concept that fails to get traction at the business level. Consequently, software companies keep trading code quality for time-to-market and new features. The resulting technical debt is estimated to waste up to 42% of developers’ time 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...

Mc91 4y ago
< using any number of 3rd party libraries (vs the developers desire to build from scratch) 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.
- twblalock 4y ago
  I would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it for as long as we need it, before I would think writing an internal log library was a good idea. 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.
  - bedatadriven 4y ago
    Writing a reliable, secure function that writes messages to stdout might be all that a project needs. 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.
    - twblalock 4y ago
      > Writing a reliable, secure function that writes messages to stdout might be all that a project needs. 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.
tnzk 4y ago
> using promises instead of observables (in a non RX codebase) Feels like the opposite?
midenginedcoupe 4y ago
Amen. 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.
- jen20 4y ago
  I’ve always explained “technical debt” to program managers in the finance industry as behaving more like an unhedged call contract than debt.
  - Domenic_S 4y ago
    Ha, I love that. Either you reap a benefit or it blows up in your face!
    - jen20 4y ago
      Or you reap benefit until it blows up in your face at an unknown time :-)
- s3tz 4y ago
  What engineers mean by debt toughly falls into two buckets. The first is actual debt, coding done on borrowed time, either consciously or unconsciously. The second is when a lack of experience, knowledge, laziness or other bad habits cause the code written to not be adaptable/agile enough to later have a low cost of change when the world changes. 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.
2T1Qka0rEiPr 4y ago
I share your perspective. Ultimately, I see the situation as somewhat analogous to having a professional work on your house. You rely on their expertise to direct what is and isn't essential, and really lack any ability to measure the outcome (e.g. is this harder wearing material or building technique really worth the extra time and money). 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.
908B64B197 4y ago
> 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 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.
- Xylakant 4y ago
  > 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. 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.
woojoo666 4y ago
> 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 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.
- satyrnein 4y ago
  "I could have built this faster if we had switched to React last year" ok but roughly how much faster? We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.
  - woojoo666 4y ago
    > 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.
- danuker 4y ago
  > And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt 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.

Mc91 4y ago

< using any number of 3rd party libraries (vs the developers desire to build from scratch) 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.

twblalock 4y ago
I would need a very strong reason to believe an internal team could build a more reliable and secure library than Log4J, and commit to support and maintain it for as long as we need it, before I would think writing an internal log library was a good idea. 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.
- bedatadriven 4y ago
  Writing a reliable, secure function that writes messages to stdout might be all that a project needs. 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.
  - twblalock 4y ago
    > Writing a reliable, secure function that writes messages to stdout might be all that a project needs. 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.

tnzk 4y ago

> using promises instead of observables (in a non RX codebase) Feels like the opposite?

midenginedcoupe 4y ago

Amen. 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.

jen20 4y ago
I’ve always explained “technical debt” to program managers in the finance industry as behaving more like an unhedged call contract than debt.
- Domenic_S 4y ago
  Ha, I love that. Either you reap a benefit or it blows up in your face!
  - jen20 4y ago
    Or you reap benefit until it blows up in your face at an unknown time :-)
s3tz 4y ago
What engineers mean by debt toughly falls into two buckets. The first is actual debt, coding done on borrowed time, either consciously or unconsciously. The second is when a lack of experience, knowledge, laziness or other bad habits cause the code written to not be adaptable/agile enough to later have a low cost of change when the world changes. 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.

2T1Qka0rEiPr 4y ago

I share your perspective. Ultimately, I see the situation as somewhat analogous to having a professional work on your house. You rely on their expertise to direct what is and isn't essential, and really lack any ability to measure the outcome (e.g. is this harder wearing material or building technique really worth the extra time and money). 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.

908B64B197 4y ago

> 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 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.

Xylakant 4y ago
> 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. 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.

woojoo666 4y ago

> 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 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.

satyrnein 4y ago
"I could have built this faster if we had switched to React last year" ok but roughly how much faster? We can't even accurately estimate (ahead of time) how long it would take in the existing stack, much less in a different one.
- woojoo666 4y ago
  > 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.
danuker 4y ago
> And also long term velocity and feature flexibility and other factors that are sacrificed when accumulating tech debt 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.