Although that is indeed the name of the paper, it is not one of the questions they answered in the paper. It seems more like "What kind of perceived flaws leads to the rejection of PRs".
The question "Does technical debt that's been already accrued lead to the rejection of new pull requests?" is what I was expecting.
Instead, the question they're asking is "Do pull requests which add technical debt to a project get rejected?" which is.. pretty obvious. That's the whole point of code review.
They go on to analyze the breakdown of what type of defect causes more discussion by doing a simple average across all of the projects they looked at, but given the visualization in Figure 2 I don't know how you can come to any real conclusion other than "it depends on the project."
Agreed. I think Technical Debt is used incorrectly here, I only consider items debt once they are merged and are intended to be fixed at a future time.
Based on the title, I was thinking it meant: Technical debt leads to project maintainers being less willing to incorporate code changes (perhaps because the code base is harder to understand?) ... which sounded plausible!
Just a reminder that the phrase Technical Debt is used a bit broadly here. In general, TD is when the codebase drifts from continuing to align with the development team's understanding of the problem. So phrases like "design" or "security" don't seem to work. At least to me.
FWIW, I wrote a blog article a few days ago on TD, including times when it might be appropriate.
I also like your wording in terms of the codebase drifting from the team's understanding of the problem, which is a drift that is important to be continually mindful of.
However, to the point of your blog post, there have definitely been others talking about when "technical debt" might be okay.[1] A big challenge is not only that people disagree on when debt is present, there really are multiple completely different definitions, and while some look a little like debt many don't behave like debt at all.
I like that definition - it fits with Martin Fowler's talk about architecture being "the important stuff" among the lead engineer's understanding of the codebase.
So architecture is the important stuff when you think about the project, and tech debt are the things that don't fit how you think about the project.
I don't really consider technical debt to be about things that make the code base harder to reason about (unreasonable?). That is an important architectural point but I think of it as orthogonal to technical debt.
To me, technical debt is about the trade-off of short term progress for long term flexibility of the code base. Essentially, the need of the business to ship -- side note: I wrote that as shit initially. Freud would be amused. -- the feature immediately outweighs the need of the business to write maintainable code. So, you expend fewer engineering resources than you should now and you spend more than you would have later. Basically, you borrow against the future productivity of your engineering team.
So, to me, it's about doing less work now and more work later. That can be a conscious decision or a consequence of ignorance. Things like choosing the wrong abstraction are about being ignorant of the problem space.
Technical debt is a metaphor, so it can have more than one meaning. My interpretation: TD is making an expedient change with long-term consequences, or mistakenly selecting tactics than undermine strategy.
It would be far more interesting to see whether code review is actually successfully rejecting code with technical debt. Is there code that passes code review and isn't identified as introducing technical debt, considered to have introduced technical debt at a later point?
Without reading the paper (don't hate), but just approaching the question as an experienced software engineer, technical debt SHOULD lead to a higher rejection of pull requests in a lot of situations.
Assumptions: Let's assume we are talking about a system with technical debt that is well understood to the maintainers, but difficult to address in a piecemeal fashion (most of them). Additionally, let's assume most pull requests are from external contributors for toy features with no deep understanding of said tech debt the features may be aggravating or making more difficult to address (most of them).
In such a state of things, it is absolutely the job of the maintainer to be extra choosy and reject more frequently pull requests that only make the task of paying down the technical debt that much harder.
Of course, taken to the extreme, this can ruin the project. But in the interim while a rewrite or refactoring or cleanup is ongoing, it may be justifiable to reject changes that constantly cause the target to move back.
Readit News
The question "Does technical debt that's been already accrued lead to the rejection of new pull requests?" is what I was expecting.
Instead, the question they're asking is "Do pull requests which add technical debt to a project get rejected?" which is.. pretty obvious. That's the whole point of code review.
They go on to analyze the breakdown of what type of defect causes more discussion by doing a simple average across all of the projects they looked at, but given the visualization in Figure 2 I don't know how you can come to any real conclusion other than "it depends on the project."
FWIW, I wrote a blog article a few days ago on TD, including times when it might be appropriate.
http://tiny-giant-books.com/blog/technical-debt-edge-cases/
However, to the point of your blog post, there have definitely been others talking about when "technical debt" might be okay.[1] A big challenge is not only that people disagree on when debt is present, there really are multiple completely different definitions, and while some look a little like debt many don't behave like debt at all.
[1] http://agilefocus.com/2012/07/02/technical-debt-the-good-the...
(I wrote that post, but it also has lots of links to other people talking about different definitions of technical debt.)
So architecture is the important stuff when you think about the project, and tech debt are the things that don't fit how you think about the project.
To me, technical debt is about the trade-off of short term progress for long term flexibility of the code base. Essentially, the need of the business to ship -- side note: I wrote that as shit initially. Freud would be amused. -- the feature immediately outweighs the need of the business to write maintainable code. So, you expend fewer engineering resources than you should now and you spend more than you would have later. Basically, you borrow against the future productivity of your engineering team.
So, to me, it's about doing less work now and more work later. That can be a conscious decision or a consequence of ignorance. Things like choosing the wrong abstraction are about being ignorant of the problem space.
Link to data used to produce paper: https://github.com/aserg-ufmg/sbsi2016-data/blob/master/Code...
Deleted Comment
Assumptions: Let's assume we are talking about a system with technical debt that is well understood to the maintainers, but difficult to address in a piecemeal fashion (most of them). Additionally, let's assume most pull requests are from external contributors for toy features with no deep understanding of said tech debt the features may be aggravating or making more difficult to address (most of them).
In such a state of things, it is absolutely the job of the maintainer to be extra choosy and reject more frequently pull requests that only make the task of paying down the technical debt that much harder.
Of course, taken to the extreme, this can ruin the project. But in the interim while a rewrite or refactoring or cleanup is ongoing, it may be justifiable to reject changes that constantly cause the target to move back.