4 ms·

The business impact of code quality (2017)

ffreitasalves 4y ago
From the Abstract and Conclusion it seems this paper was driven to show a specific result instead of discovering something. As the author wrote in the conclusion: "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.
reedlaw 4y ago
The paper uses the term "technical debt" without defining it. From the context the term is used in its popular sense in which the primary source of debt is writing code poorly. Ward Cunningham, who coined the term, did not mean it in this way [1]. Wikipedia defines it as "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. The problem with the current understanding of the technical debt metaphor is that it justifies poor code quality. Apparently it's like taking out a loan to make a sound investment. 1. https://youtu.be/pqeJFYwnkjE?t=196 https://youtu.be/pqeJFYwnkjE?t=196 2. https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt
- andsoitis 4y ago
  > "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. 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.
- Domenic_S 4y ago
  They define it in the second sentence as "trading code quality for time-to-market and new features". Section 2 defines code quality ("This section defines the metrics for code quality"), which is helpfully (/s) measured by the tool they sell.
  - rileymat2 4y ago
    Assuming that they ran the experiment in earnest, doesn't that strongly indicate that whatever code quality metrics in their product target are a pretty good signal? (Until people target those metrics)
  - reedlaw 4y ago
    Quite right. Thus they implicitly equate poor quality code with technical debt. This makes the metaphor unsuited to a proper aversion to poor quality code. If it's simply debt it can be paid off later with a small amount of interest. Such a conclusion is contrary to the one the paper is trying to put forth.
jelling 4y ago
> 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.
__alexs 4y ago
This "paper" is just a glorified advert for CodeScene.
danuker 4y ago
I see that CodeScene's Code Health metric mostly looks at complexity and churn. Here is a Ruby tool that gives you a similar report: https://github.com/chad/turbulence https://github.com/chad/turbulence And a Python one: https://github.com/danuker/lookout/tree/nohardcode https://github.com/danuker/lookout/tree/nohardcode

From the Abstract and Conclusion it seems this paper was driven to show a specific result instead of discovering something. As the author wrote in the conclusion: "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.

reedlaw 4y ago

The paper uses the term "technical debt" without defining it. From the context the term is used in its popular sense in which the primary source of debt is writing code poorly. Ward Cunningham, who coined the term, did not mean it in this way [1]. Wikipedia defines it as "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. The problem with the current understanding of the technical debt metaphor is that it justifies poor code quality. Apparently it's like taking out a loan to make a sound investment. 1. https://youtu.be/pqeJFYwnkjE?t=196 https://youtu.be/pqeJFYwnkjE?t=196 2. https://en.wikipedia.org/wiki/Technical_debt https://en.wikipedia.org/wiki/Technical_debt

andsoitis 4y ago
> "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. 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.
Domenic_S 4y ago
They define it in the second sentence as "trading code quality for time-to-market and new features". Section 2 defines code quality ("This section defines the metrics for code quality"), which is helpfully (/s) measured by the tool they sell.
- rileymat2 4y ago
  Assuming that they ran the experiment in earnest, doesn't that strongly indicate that whatever code quality metrics in their product target are a pretty good signal? (Until people target those metrics)
- reedlaw 4y ago
  Quite right. Thus they implicitly equate poor quality code with technical debt. This makes the metaphor unsuited to a proper aversion to poor quality code. If it's simply debt it can be paid off later with a small amount of interest. Such a conclusion is contrary to the one the paper is trying to put forth.

jelling 4y ago

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

__alexs 4y ago

This "paper" is just a glorified advert for CodeScene.

danuker 4y ago

I see that CodeScene's Code Health metric mostly looks at complexity and churn. Here is a Ruby tool that gives you a similar report: https://github.com/chad/turbulence https://github.com/chad/turbulence And a Python one: https://github.com/danuker/lookout/tree/nohardcode https://github.com/danuker/lookout/tree/nohardcode