Ward Cunningham coined the metaphor “technical debt” back in 1992, using it to illustrate the long term cost of moving quickly and cheaply when architecting software. As with fiscal debt, not all debt is bad. But all debt requires strategic maintenance, Martin Fowler wrote a best seller centred around the topic of combating this technical debt through re-factoring, unit testing & deleting dead code. As he says himself…
This is the book that I’m proudest of, in that it’s had a high impact on the world of software development.
We’re all aware of this debt, managing it is a pain but it means better maintainability and extendibility of our systems. Without which, we’d endure some excruciating costs down the line as debts compound.
But with the rise of machine learning, the costs have gone up. We have more debt to manage, if this debt is not exposed and allowed to compound in silence, we’re going to end up with a hefty bill in the mail.
This was one of the topics presented at NIPS, the Google team shared some of their development experience in a paper titled Hidden Technical Debt in Machine Learning. Their paper aims to highlight the additional costs of developing machine learning algorithms, extending this notion of technical debt even further.
One of the main issues they raise has to do with the entangled nature of machine learning itself which is highlighted by the CACE principle: Changing anything, changes everything. Ask any data scientist or machine learning researcher and they’ll tell you that this principle isn’t surprising at all.
In fact altering features, thresholds or learning settings can produce an entirely new algorithm, its one of machine learning’s strengths. Issues only arises when you come to maintenance, abstraction boundaries which once helped express invariants and/or logical consistencies no longer work.
The paper goes on to highlight other issues such as, correlation cascades, configuration management and undeclared consumers. One of the more interesting sections is where they talk about hidden and visible feedback loops, giving the following scenario as an example.
Consider the case of two stock-market prediction models from two different investment
companies. Improvements (or, more scarily, bugs) in one may influence the bidding and buying
behavior of the other.
I highly suggest reading through the paper, if for nothing else but section seven which talks about dealing with changes in the external world. I personally found it to be the most informative section.