13 ML development hubris

 

This chapter covers

  • Applying refactoring to overengineered implementations to increase development velocity
  • Identifying code to target for refactoring
  • Establishing simplicity-driven development practices
  • Adopting new technologies via sustainable means
  • Comparing build, buy, and prior art in implementations

The preceding chapter focused on critical components used to measure a project’s overall health from a purely prediction-focused and solution efficacy perspective. ML projects that are built to support longevity through effective and detailed monitoring of their inputs and outputs are certainly guaranteed to have a far higher success rate than those that do not. However, this is only part of the story.

Another major factor in successful projects has to do with the human side of the work. Specifically, we need to consider the humans involved in supporting, diagnosing issues with, improving, and maintaining the project’s code base over the lifespan of the solution.

Note

When a project is released to production, that is merely the beginning of its life. The real challenge of ML is to keep something running well over a long period of time.

This human element comes in the following form:

13.1 Elegant complexity vs. overengineering

13.1.1 Lightweight scripted style (imperative)

13.1.2 An overengineered mess

13.2 Unintentional obfuscation: Could you read this if you didn’t write it?

13.2.1 The flavors of obfuscation

13.2.2 Troublesome coding habits recap

13.3 Premature generalization, premature optimization, and other bad ways to show how smart you are

13.3.1 Generalization and frameworks: Avoid them until you can’t

13.3.2 Optimizing too early

13.4 Do you really want to be the canary? Alpha testing and the dangers of the open source coal mine

13.5 Technology-driven development vs. solution-driven development