A very useful concept in software engineering is technical debt. Technical debt occurs when engineers choose a quick but suboptimal solution to a problem, or don’t spend time to build sustainable infrastructure. Maybe they’re using an approach that doesn’t scale well as the team and codebase expand (such as hardcoding “magic numbers”), or using a tool for reasons of convenience rather than appropriateness (“we’ll write the DevOps infrastructure in PHP since that’s what our team already knows”).
Scientific debt is when a team takes shortcuts in data analysis, experimental practices, and monitoring that could have long-term negative consequences. When you hear a statement like:
- “We don’t have enough time to run a randomized test, let’s launch it”
- “To a first approximation this effect is probably linear”
- “This could be a confounding factor, but we’ll look into that later”
- “It’s directionally accurate at least”
you’re hearing a little scientific debt being “borrowed”.
Source: Scientific debt