It is super clear that people involved with ML/DS type of work, are really really smart.

Individuals in this field know about statistics, machine learning, academic research, data manipulation, and they excel at reasoning, and logical thinking beyond belief.

However, as these talented individuals transition to working with software engineers and product managers, on live products, they notice a deep sense of instability.

The reality is that software is an intensely creative activity but produces tremendously fragile artifacts.

Now, if traditional software products are fragile and can be taken down by flipping a single IF condition at the right place, one can only imagine the fragility of ML software.

How can something so valuable for company profits, and society as a whole be so fragile? And how can this fragility be so unexplored by ML practitioners?

Not into reading? Checkout the companion 5 hours video course + book bundle:

https://www.udemy.com/course/clean-machine-learning-code

If you read this far, you are well aware that there is no useful Machine Learning (ML) without extensive software. But building complex software comes with many challenges.

ML software is explicitly full of needless complexity and repetition. Thick opacity, rigidity, and viscosity of design magnify this brew of complexity. With these issues, ML failures are growing in importance at an unprecedented pace.

It does not have to be this way.

As a global data science community, the autonomous systems we build can be costly, dangerous, and even deadly. Adding to the problem is the inexperienced workforce of this 5 to 10 years old craft. As of 2019-2020, 40% of data scientists in the USA have less than 5 years of experience.

The software industry is experiencing a boom in ML development and usage. This is not unlike previous software engineering booms in the early 2000s. The current boom manifests itself with a menagerie of constructs, abstractions, frameworks, and workflows. This multitude of integration challenges remind us of old and classical software problems. Some of the issues present in the ML software engineering practice are new. But the majority of the software engineering concerns have a historical smell. Going back to the early days of software engineering can help with today’s ML problems.

For us, ML engineers, it is time to stop reinventing the wheel, making the same old mistakes, and start using the decades of successful software engineering practices by replacing “Software” with “Machine Learning Software”.

This book can help with that.