Software engineering practices need to be in place before teams adopt higher-level data science practices.
2
An ML product depends on data science, software engineering, and governance, with automation adding value as systems grow.
3
Automatic retraining is useful when a product has a valuable feedback loop, but many companies get little value from retraining on a fixed schedule.
Summary
Phil Winder argues that MLOps needs to include the software and organizational foundations underneath machine learning. Practices such as continuous training, provenance, and reproducibility have limited value when a company lacks basic software version control, infrastructure, or operating processes. He maps ML work across three areas: data and models, software engineering, and governance. Each area has a basic level needed to release a product, practices that become valuable at scale, and an optimal level with extensive automation. Winder describes a production setup in which data scientists use hosted notebooks, training runs are launched through Kubeflow, models are stored in MLflow, and deployed models feed results back into a continuous learning pipeline. He is careful about automatic retraining. It makes sense when user feedback provides useful new data and model quality can be checked, while scheduled retraining often adds little value for smaller products. He also discusses team design, shared language, diversity of experience, and the difficulty of asking one person to cover an ever-growing technical stack.
Higher-level ML practices depend on ordinary software engineering
Winder says his immediate reaction to the MLOps manifesto was that reproducibility, accountability, collaboration, and continuity are good practices, but they do not cover everything a team needs. Much of his daily work is software engineering rather than data science. Continuous training has little meaning if a company does not even have software version control. He points out that some companies are still moving away from environments with no version control, so teams should deal with those foundations before focusing on advanced ML practices. The data science layer sits on top of software, infrastructure, and the processes that allow a team to build and run a product.
ML work has three layers, with value increasing as systems scale
Winder describes an ML hierarchy using a table rather than a pyramid. Its rows cover data and models, software engineering, and governance. Governance includes the team, company, and processes needed to organize the work. Its columns describe what is required to make a product viable, what starts adding value as the number of products grows, and an optimal state. Automation appears across all three areas. A basic product can exist without full automation or model provenance, but those practices become valuable when teams operate more products and need to move backwards and forwards through the history of data, code, and models.
Monitoring ML systems needs more than summary statistics
Winder describes monitoring work built around Kubernetes, with tools such as Prometheus, Grafana, and the Elastic stack. These tools help teams monitor services and logs, but he sees a gap in the way software engineering monitoring is applied to data science. Teams often rely on low-resolution data and single summary statistics. ML applications may need distributions, comparisons between distributions, and other data-specific views. Adding that support often requires custom code. He places visibility in the governance area because monitoring is part of the wider process of knowing whether a product is working and whether customers can use it.
An ML product needs data, modeling skills, software, infrastructure, and organizational backing
When Winder expands the data layer, he starts with raw data and the skills needed to analyze it and understand the problem. A team also needs to choose a modeling paradigm, such as supervised, reinforcement, or unsupervised learning. Model architecture, training, serving, and evaluation follow from that choice. He says these elements are needed to release even a basic data product, along with the software and infrastructure underneath them. The work also needs a team or company with enough structure to build and operate the product. This is why data science cannot be separated cleanly from software engineering and governance.
Teams need shared responsibility rather than a chain of handoffs
Winder recalls a pattern in which a data scientist writes an algorithm, hands it to a software engineer, and expects someone else to implement it correctly before operations takes over. The groups then complain that the other side does not understand the work. He supports bringing data scientists into the software and operations team so the group can own and deliver ML systems together. The difficulty is that the full stack keeps expanding, while organizations increasingly expect one person to cover it. He sees room for both broad generalists and deep specialists, with generalists fitting fast-moving work and specialists fitting problems that require sustained focus.
The hardest part of scaling is often the team and its culture
Winder says platform barriers are getting lower as products and services make ML infrastructure easier to assemble. Team design is harder because the technical stack keeps growing and organizations change their teams frequently. Larger companies can combine people with different expertise, while smaller teams often need people who can move across several areas. Winder also stresses diversity of experience and background because a narrow team can limit its view of a problem. He describes cross-functional teams, mutual respect, and learning through day-to-day collaboration as practical ways for software engineers and data scientists to understand each other's work.
Provenance and data validation make failures diagnosable
For larger organizations with many data projects, Winder describes provenance as knowing where the production artifact came from. That includes the software, data, and trained model, each tied to a specific point in time. When a prediction is wrong, the team can inspect the exact inputs, code, and model involved. This depends on packaging artifacts correctly and having pipelines that build them repeatably. He also says most projects he encounters do not validate data before it enters the system. Missing or malformed data then causes failures that teams accept as normal. Data validation belongs in the production workflow alongside software testing and continuous integration.
Automatic retraining should follow product value and usable feedback
Winder describes automatic retraining as an optimal pattern when a product has a natural feedback mechanism. Users may provide new data or indicate whether a prediction was useful. A continuous learning pipeline can collect that feedback, trigger a new training run, compare the new model with the old one, and deploy it after checking that quality has not fallen. He says most companies are still retraining manually or on a cron schedule, such as once a day. That can work because many products do not change enough to justify continuous retraining. The decision depends on the value of retraining, not on whether a practice is fashionable or technically possible.
"There was this level of there was this kind of idea of but it is valuable it becomes valuable over time when you have more and more in production."Phil Winder22:22
Who should watch
You are building an ML platform and need a way to decide which engineering practices belong in the first release.
Your team is debating continuous retraining, provenance, or monitoring and needs a value-based way to choose what to automate.
Data scientists, software engineers, and operations staff are struggling with handoffs and need a shared model for ownership and team design.
