
Does technical debt lead to the rejection of pull requests? - nextjj
http://arxiv.org/abs/1604.01450
======
mikekchar
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".

~~~
driusan
I was pretty disappointed by the title too.

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

~~~
pklausler
Identifying technical debt is certainly part of a good code review process,
but it's hardly the "whole point".

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

[http://tiny-giant-books.com/blog/technical-debt-edge-cases/](http://tiny-
giant-books.com/blog/technical-debt-edge-cases/)

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

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

------
nxzero
Direct link to the PDF:
[http://arxiv.org/pdf/1604.01450v1.pdf](http://arxiv.org/pdf/1604.01450v1.pdf)

Link to data used to produce paper: [https://github.com/aserg-
ufmg/sbsi2016-data/blob/master/Code...](https://github.com/aserg-
ufmg/sbsi2016-data/blob/master/Code%20Review.zip)

~~~
jalanb
Typo in he pdf link, should be:
[http://arxiv.org/pdf/1604.01450v1.pdf](http://arxiv.org/pdf/1604.01450v1.pdf)

~~~
jalanb
Muphry strikes again :-)

~~~
happysadpanda
Murphy, or Muphry? I am expecting Murphy to screw up my reply in some way ;)

------
DasIch
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?

------
xyzzy4
I first question the premise - why does there need to be pull requests? Maybe
just let people commit what they want to commit.

~~~
DasIch
That's not the premise. On most projects people probably also do exactly that.

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

~~~
hashkb
Yes hate! Read the paper!

