Does technical debt lead to the rejection of pull requests?
arxiv.org
arxiv.org
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.
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...
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.