Notebooks Are for Exploration, Not Execution
Computational notebooks have become a staple of exploratory data science. Originating with Wolfram Mathematica and now popular among Python and R users, they combine a runnable script with visualization and documentation in a single interactive window. That makes them excellent for two things: interactive exploration and demos. They are not essential to doing data science, and many practitioners don’t use them at all.
The temptation to take a working notebook and drop it straight into a production codebase is understandable. The idea behind the notebook—explore, iterate, arrive at a result—has produced something of value. But that artifact is not structured for the demands of production software. Deploying it as-is violates a number of sound engineering practices and, predictably, leads to observed pain points. The root cause is usually a deeper gap: data scientists and software developers not collaborating closely enough.
Why Notebooks and Spreadsheets Share the Same Limits
Notebooks share a great deal with spreadsheets, both in strengths and weaknesses. They let people with limited programming experience perform useful quantitative work. Scripting is the first step toward general programming, and both tools combine storage, visualization, and business logic into one application. That one-stop-shop nature is an advantage when things are simple. Calculating payroll for a dozen employees at a startup is a perfect spreadsheet job. Running payroll for an international bank is not.
Complexity is the dividing line. Large applications built by teams succeed only when complexity is controlled, and the primary tool for that is decomposition. In the Presentation Domain Data Layering pattern, for instance, UI, domain logic, and storage are separated so each concern can be considered without the noise of the others. A notebook drops into that picture as a fully powered shell, mixing all three concerns into one file, along with the experimental code that led to the final logic. That extra code will confuse anyone who later has to modify the system. A shell with full manual tinkering capability is also a hazard inside a production environment, which requires reproducibility and auditability over interactive convenience. Even well-intentioned operators can cause unintended harm.
What Should Move Into Production
What belongs in the production codebase is the concluding domain logic and, where necessary, the visualizations. In most cases this is not a difficult extraction. Notebooks encourage linear scripting, which tends to be small and straightforward to move into a structured codebase. If the logic is large enough to be complex, that raises the question of how we know it works at all. Scripts are fine for a few lines, not for dozens. Breaking that logic into smaller, modular, testable pieces lets the team verify correct behavior and reuse code without duplication.
The Real Issue Is Collaboration
Given that moving notebooks into production is neither safe nor hard to avoid, why does the question keep coming up? The essence of the problem is communication. Many data scientists do not fully grasp the concerns of professional software development—automated, reproducible builds, thorough testing, and the design practices that keep codebases supportable. Many software developers, in turn, do not understand what data scientists actually do.
This is not a situation where two groups can work in isolation and hand off artifacts. The advantages come when data scientists learn software development and work fully embedded in the delivery team responsible for production software. They do not need to reach full capacity as developers, but they need a solid grasp of the basics and should keep learning in areas relevant to their work. Developers who understand a bit more about data science make far better use of its models and methods. Neither side needs to become an expert in the other’s field, but both should aim for competence in the fundamentals.
Building Experimentation Into the Pipeline
Data scientists will find that applying software development techniques makes them more productive, enabling more complex tasks and far less time spent debugging. The shift happens once an approach has been settled on: focus moves to building a structured codebase around that approach while preserving the ability to experiment. The way to preserve experimentation is to build it into the pipeline itself.
One example is a machine learning model registry that allows parameters to be modified at run-time or build-time while storing results, such as performance metrics, in a data store. Because experiments run with versioned code and results are retained for comparison, they are always repeatable. Differences in effect can then be traced to intended causes—the hallmark of a good experiment. This approach also ensures any change in effect can be demonstrated to stem from an intended cause. Ultimately the goal is to learn what changes to production software create more business value, and the smaller the gap between the experiment environment and the actual implementation, the more confident we can be. Building data science pipelines that run on production servers, on build servers, and locally on a laptop further enables experimentation without disrupting production.
Aim for Value, Not Notebooks
The conversation about how to productionize notebooks misses the point. The goal is to empower data scientists and their delivery teams to build software that delivers business functionality while retaining the capacity to experiment and improve. That requires leaving notebook-style development behind after the initial exploratory phase rather than propping it up with constant integration support. This way of working not only lets data scientists improve working software, it includes them in the responsibility of delivering value to the business.
