6 ms·
Does technical debt lead to the rejection of pull requests?
- nxzero 11y agoDirect 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%20Review.zip https://github.com/aserg-ufmg/sbsi2016-data/blob/master/Code...
- jalanb 11y agoTypo in he pdf link, should be: http://arxiv.org/pdf/1604.01450v1.pdf http://arxiv.org/pdf/1604.01450v1.pdf
- jalanb 11y agoMuphry strikes again :-)
- nxzero 11y agoThanks, updated the link!
- happysadpanda 11y agoMurphy, or Muphry? I am expecting Murphy to screw up my reply in some way ;)
- mikekchar 11y agoAlthough 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".
- jjmanton 11y agoAgreed. 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.
- madeofpalk 11y agoTechnical Debt in a PR is just a 'bad purchase'
- aidenn0 11y agoNo, it's a purchase on credit. It's only a 'bad purchase' if the long-term result is a net-negative.
- driusan 11y agoI 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 11y agoIdentifying technical debt is certainly part of a good code review process, but it's hardly the "whole point".
- artpepper 11y agoBased 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!
- DanielBMarkham 11y agoJust 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 11y agoI 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 11y agoI 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.
- pklausler 11y agoTechnical 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.
- deanCommie 11y agoWithout 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 11y agoYes hate! Read the paper!
- xyzzy4 11y agoI first question the premise - why does there need to be pull requests? Maybe just let people commit what they want to commit.
- DasIch 11y agoThat's not the premise. On most projects people probably also do exactly that.
- deleted 11y ago[deleted]
- DasIch 11y agoIt 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?