Paper:
Hidden Technical Debt in Machine Learning Systems
Machine learning offers a fantastically powerful toolkit for building useful complex prediction systems quickly. This paper argues it is dangerous to think of these quick wins as coming for free. Using the software engineering framework of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems. We explore several ML-specific risk factors to account for in system design. These include boundary erosion, entanglement, hidden feedback loops, undeclared consumers, data dependencies, configuration issues, changes in the external world, and a variety of system-level anti-patterns.

Review:
The paper shines the light on the systems aspect of the design and maintenance of the ML systems.This is not a typical NIPS paper as it does not propose new methodology.However, there are barely any papers of its ilk despite the fact that most major corporations which make decisions based on data are employing some version of a ML system.Technical debt leads to high overhead in maintenance which carries significant monetary costs to the companies.By summarizing major issues associated with the maintenance of such systems (and thus potentially helping avoid some of the pointed out issues), this paper will have a *very* significant impact on the development of new ML systems.I very much enjoyed reading the paper.The paper resonates very strongly with me as after many years as a university ML researcher, I recently left to join industry, and over the last two years, I have observed first-hand the systems issues described in the paper.The authors did a great job summarizing the main pitfalls.I could add a few points to the taxonomy even though it is already quite comprehensive: - (Intro) Deploying ML systems carries its own overhead as well manifesting in running of A/B experiments (and then cleaning up after them) and maintaining an archive of artefacts for deployed models. - (ML-System Anti-Patterns) When reading about the Glue Code, I cannot help but think of incorporating open source packages into the system, especially if additional custom modifications need to be made.Using these packages leads to several potential (unmentioned) headaches: (1) someone needs to maintain this package internally, (2) whenever there is an updated version of the package, it needs to be re-integrated into the internal code-base, and (3) if internal modifications we made, they often need to be committed back to the open source (to maintain future compatibility); this may require jumping through administrative hoops. - (Configuration Debt) It is worth mentioning that interruptions in data logging may lead not only to stale features but also to (potentially cascading) failures in feature builds. - (Monitoring and Testing) Additional aspect could be changes in available bandwidth, both to extract/build the features and to train the model.Typos: - Page 2 (Correction Cascades) $a$ -> $m_a$ (two places) - Page 3, line 131, the -> them