Ward Cunningham introduced the concept of technical debt in 1992 to explain the consequences of choosing the quick solution instead of the best solution. Under this framework, in software development, releasing the quick and easy solution incurs technical debt. The interest on this debt comes in the form of additional work required to restructure the code in the future.
Cunningham further says:
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.“The WyCash Portfolio Management System”.
So, just like financial debt can help you make financial investments faster and seize time-sensitive opportunities; technical debt can help seize business opportunities by meeting critical market needs. This makes perfect sense to me for software development and product design.
Then, I read David Robinson’s attempt to extend this idea to data and analytics, calling it scientific debt. He states:
“Scientific debt is when a team takes shortcuts in data analysis, experimental practices, and monitoring that could have long-term negative consequences.”David Robinson
This is where I disagree. All the ways that a company may incur “scientific debt”, such as lack of monitoring, flawed analyses, lack of data infrastructure, sound like bad data practices. Not conducting a A/B test to fix a typo is not a scientific debt or a shortcut, it is just good judgement. Correlation does not imply causation – this is also not a shortcut, it is logic.
Refactoring, i.e. rewriting an existing code, is how you pay off technical debt. By extension, the scientific debt has to be paid off by re-analyzing or re-designing the experiment. However, this introduces all sorts of biases, such as confirmation bias, hindsight bias, overconfidence, anchoring etc. If the data is being analyzed to inform a business decision, it is critical to come up with decision criteria before a model is built.
Suppose you are deciding whether or not you want to watch a particular movie. You want to make your decision based on critics’ rating. A quick online search tells you that the average rating of the movie is 7.8 out of 10. Is this a good number? May be. Depends on which way you were leaning all along, even before you found out the critics rating.
If your pre-existing desire was to watch the movie then you might justify by saying “It’s almost 8 out of 10!”. If you didn’t want to go through the trouble all along, you might say “Why would I want to spend my time and money on a movie that didn’t even get an 8 out of 10!”. However, if you had set your decision criteria before looking at the number, the 7.8 would actually mean something.
Similarly, if you do not commit to data collection, statistical testing and point of action in advance, you are not making a data-informed decision. You are making yourself feel better about the decision you already made.
Looking Elsewhere Effect
The idea of “scientific debt” also opens the door to the Looking Elsewhere Effect or the Multiple Testing Problem, which states that the probability a researcher wrongly concludes that there is at least one statistically significant effect across a set of tests, even when in fact there is nothing going on, increases with each additional test.
In other words, if you look in large enough area, persistently enough, you will find a significant effect somewhere. The likelihood of finding something in the entire area you searched is greater than it would be if you had stated beforehand where you think the effect would be found, because of the “probability boost” of looking in many places.
So you may end up making a decision on a false positive in an attempt to pay off “scientific debt”.
While software development relies on logic (if A, then B), data science relies on probability (If A then probably B). As such data science projects must quantify uncertainty. From the assumptions we make, the observations we include, to the predictions and generalizations we extend, involve uncertainty of different types and to different degrees.
Incurring scientific debt is suggested as a way to avoid overthinking. However, the way to deal with overthinking or analysis paralysis is by appreciating that no matter the knowledge or the model, there will always be something that is not known. Recognizing, understanding and communicating the uncertainty contained in an analysis or a model can done in terms of a probability distribution or confidence intervals or likelihood ratios.
Science is characterized by:
…the greater care in excluding possible alternative explanations, the more detailed elaboration with respect to data on which predictions are based, the greater care in detecting and eliminating sources of error, the more articulate connections to other pieces of knowledge, etc. On this position, what characterizes science is not that the methods employed are unique to science, but that the methods are more carefully employed.Stanford Encyclopedia of Philosophy
Careful employment of statistical techniques is the cornerstone of data science. It is only possible to draw valid conclusions from statistics if all the analysis are planned ahead, the plan is executed rigorously and the results are communicated transparently. Scientists do not have the luxury of taking on a debt at the expense of rigor and reliability of their findings.