Increasing, Not Diminishing: Investigating Returns of Highly Maintainable Code | Hacker News Reader

Increasing, Not Diminishing: Investigating Returns of Highly Maintainable Code

arxiv.org

26 pointsmfiguiere8 comments

Code quality is very subjective. Assuming you eliminate the extreme cases of poor code and great code, most people being average, the best thing to do is keep a talented team together as long as possible. The team will accrue knowledge slowly at first but will produce dividends later on as they will have the best knowledge of the system.

Excluding extremely poor situations it is domain knowledge that drives defects, not the code.

That sounds ideal, but hard to control ultimately. Pay and opportunities for growth are typically going to be constrained at most places long term.

It seems like it's worth identifying weak spots in your codebases where higher complexity is lying, you have sole contributors on your team, or buggy areas. Armed with the information, you can plan ahead for them. Would refactoring into a different design better manage the complexity? Can we get more team members involved in changes to parts of a system we don't have familiarity with, for redundancy? Why are we fielding so many bugs in this functionality and how do we mitigate it?

> Code Health (CH) is quantified through the CodeScene tool, yielding a numeric and absolute value that ranges between 10 (top-notch code quality) and 1 (extremely poor code quality).

Three of the four researchers are associated with the company behind CodeScene and the datasets are provided by CodeScene’s customers. They’re somewhat acknowledging this bias, but it might be good to know about before you take this for a fact and cite it based on the title alone.

Has 'Technical Debt' become a formal term now?

It's been a formal term for quite a while now, has it not?

Most everyone agrees that technical debt is a real thing, but I don’t think we’ve landed on a widely accepted formal definition of what it is. Tech debt is so often used as a qualitative health term with no quantitative metrics behind it.

This paper establishes what it defines as tech debt, but it’s certainly not universal.

I don't think the paper actually defines what TD is. If it does, I can't find it. Isn't TD any code that goes to production? And, in this paper, code quality is whatever they say it is, or at least what their tool says it is. It's all a bit circular, don't you think?

Technical debt is (was supposed to be, in its original meaning) an explicit decision to do something easy now that would have to be refactored/rewritten for something you know is coming later. You're trading time now for time from the future, that's why it was called "debt". It gets used colloquially for much more than that nowadays though.

Reply on news.ycombinator.com