4 ms·

This abstraction of debt doesn't really work for me...

treehau5 10y ago
Great! Do you mind expanding on why it doesn't work for you with emphasis on the relevant, objectifiable aspects? (as objectifiable as you can be for an anecdote, of course!)
- debtor123 10y ago
  I thought I was being clever, since the author mentioned bad abstractions as a kind of research debt...
- milesvp 10y ago
  I'll take a shot. What's actually being described in the article is entropy. Entropy counts always go up, and it takes energy to fight entropy. Or to put it another way, it takes more effort to produce simple writings, than it does to make complicated writings (especially for things that appear inherently complex). This means that debt isn't the right term here, because debt is something that must be paid back by the individual, or organization that took out the loan. It also requires a lender, which, if we're talking about technical debt, is usually future you. In terms of publishing papers, the author isn't borrowing effort from his own future, he's simply not doing work that he doens't need to do. The problem the article is talking about is that others have to do work because the author didn't do work. This is not debt, it's something else (I'm sure there's a term for it in economics, the closest I can think of would be some subtle variant of a negative externality). While I agree that research would be easier if authors spent more time distilling their ideas, that effort is a public good, and effort that will largely not have a positive expected ROI for the author, even if there is a huge ROI from a community collective point of view.
  - colah3 10y ago
    I agree that when you think about individual researchers it's a negative externality -- in many cases, the researcher doesn't pay, but other members of the research community do. This is true in programming as well: often the technical debt falls on your collaborators. You understand that crazy code you wrote and didn't document, but no one else does. For the debt perspective to really work, you need to think of the research community as a team working together to advance science. Individual members of that team take out debt to advance their work faster, but in the long run it costs the team more.
btown 10y ago
As a company or individual, when you take on debt, when you become "highly leveraged," all is good as long as that allows you to grow. But if your growth (and ability to repay) stagnates, then you enter a difficult situation where you are unable to effectively make (or attract) investment in themselves, because the overhead inherent in that debt load (interest payments, risk-averse behavior for fear of default) would eat away at the returns of any additional investment. That overhead must be paid down, at great distraction and opportunity cost, before future investment makes sense. "Research debt" and "technical debt" are much the same; corners cut, such as lack of approachable documentation (which is exactly the "distillation" mentioned in the original post), may allow a small group of researchers/engineers to move quickly in the short term, but it can lead to development stagnation in the medium term as newcomers are unable to contribute; this is analogous to later investment being less effective. While many a CTO can understand the importance of paying down technical debt to allow for continued growth, it's much more difficult for a researcher to make that justification. So the analogy is a helpful one.
- debtor123 10y ago
  When programmers talk about technical debt, I understand the analogy. A project has technical debt if it has these early "corner cuts" that need to be paid off in order to move forward faster. So wouldn't research debt be something a researcher has accumulated when she "cut corners" and didn't learn all she needed to learn? Who needs to pay off this debt? And distillation as the opposite somehow of debt? Surely a researcher needs to pay off her own research debt by researching. Sorry for nitpicking. It seems like people here enjoy the analogy.
  - btown 10y ago
    Nobody's saying that researchers are cutting corners on their own learning; it's that once they make discoveries, they're not prioritizing effective communication to others in the field. When there's a general understanding that "someone's figured out a set of techniques for the state of the art in niche subfield X, but god help us if we want to actually build on those techniques, or evaluate their approach, because there's barely any learning path to get to that person's level" then research in that niche slows down, because new researchers are more incentivized to find areas where they can realistically push boundaries. So it's not the researcher per say that accumulates debt, it's the research field overall. It's exactly the same problem as if only a few experts in a software engineering group could be trusted to refactor a codebase because there aren't tests or other systems to help others get to their level of knowledge. And whereas engineering management might be able to tell the experts to disseminate their knowledge (pay down technical debt), in academia the experts will often just continue to work with the colleagues and collaborators already at their level. Pedagogy and prodigy don't always go hand in hand.

Great! Do you mind expanding on why it doesn't work for you with emphasis on the relevant, objectifiable aspects? (as objectifiable as you can be for an anecdote, of course!)

debtor123 10y ago
I thought I was being clever, since the author mentioned bad abstractions as a kind of research debt...
milesvp 10y ago
I'll take a shot. What's actually being described in the article is entropy. Entropy counts always go up, and it takes energy to fight entropy. Or to put it another way, it takes more effort to produce simple writings, than it does to make complicated writings (especially for things that appear inherently complex). This means that debt isn't the right term here, because debt is something that must be paid back by the individual, or organization that took out the loan. It also requires a lender, which, if we're talking about technical debt, is usually future you. In terms of publishing papers, the author isn't borrowing effort from his own future, he's simply not doing work that he doens't need to do. The problem the article is talking about is that others have to do work because the author didn't do work. This is not debt, it's something else (I'm sure there's a term for it in economics, the closest I can think of would be some subtle variant of a negative externality). While I agree that research would be easier if authors spent more time distilling their ideas, that effort is a public good, and effort that will largely not have a positive expected ROI for the author, even if there is a huge ROI from a community collective point of view.
- colah3 10y ago
  I agree that when you think about individual researchers it's a negative externality -- in many cases, the researcher doesn't pay, but other members of the research community do. This is true in programming as well: often the technical debt falls on your collaborators. You understand that crazy code you wrote and didn't document, but no one else does. For the debt perspective to really work, you need to think of the research community as a team working together to advance science. Individual members of that team take out debt to advance their work faster, but in the long run it costs the team more.

btown 10y ago

As a company or individual, when you take on debt, when you become "highly leveraged," all is good as long as that allows you to grow. But if your growth (and ability to repay) stagnates, then you enter a difficult situation where you are unable to effectively make (or attract) investment in themselves, because the overhead inherent in that debt load (interest payments, risk-averse behavior for fear of default) would eat away at the returns of any additional investment. That overhead must be paid down, at great distraction and opportunity cost, before future investment makes sense. "Research debt" and "technical debt" are much the same; corners cut, such as lack of approachable documentation (which is exactly the "distillation" mentioned in the original post), may allow a small group of researchers/engineers to move quickly in the short term, but it can lead to development stagnation in the medium term as newcomers are unable to contribute; this is analogous to later investment being less effective. While many a CTO can understand the importance of paying down technical debt to allow for continued growth, it's much more difficult for a researcher to make that justification. So the analogy is a helpful one.

debtor123 10y ago
When programmers talk about technical debt, I understand the analogy. A project has technical debt if it has these early "corner cuts" that need to be paid off in order to move forward faster. So wouldn't research debt be something a researcher has accumulated when she "cut corners" and didn't learn all she needed to learn? Who needs to pay off this debt? And distillation as the opposite somehow of debt? Surely a researcher needs to pay off her own research debt by researching. Sorry for nitpicking. It seems like people here enjoy the analogy.
- btown 10y ago
  Nobody's saying that researchers are cutting corners on their own learning; it's that once they make discoveries, they're not prioritizing effective communication to others in the field. When there's a general understanding that "someone's figured out a set of techniques for the state of the art in niche subfield X, but god help us if we want to actually build on those techniques, or evaluate their approach, because there's barely any learning path to get to that person's level" then research in that niche slows down, because new researchers are more incentivized to find areas where they can realistically push boundaries. So it's not the researcher per say that accumulates debt, it's the research field overall. It's exactly the same problem as if only a few experts in a software engineering group could be trusted to refactor a codebase because there aren't tests or other systems to help others get to their level of knowledge. And whereas engineering management might be able to tell the experts to disseminate their knowledge (pay down technical debt), in academia the experts will often just continue to work with the colleagues and collaborators already at their level. Pedagogy and prodigy don't always go hand in hand.