PROCESS AND TECHNICALPROCESS AND TECHNICALDEBTDEBT

Christian Kaestner

Required Reading:

Sculley, David, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary,Michael Young, Jean-Francois Crespo, and Dan Dennison. "

." In Advances in neural information processing systems, pp. 2503-2511. 2015.

Suggested Readings:

Fowler and Highsmith. Steve McConnell. So�ware project survival guide. Chapter 3Kruchten, Philippe, Robert L. Nord, and Ipek Ozkaya. "

." IEEE So�ware 29, no. 6 (2012): 18-21.

Hidden technical debt in machine learningsystems

The Agile Manifesto

Technical debt: From metaphor to theory andpractice

1 . 1

LEARNING GOALSLEARNING GOALSOverview of common data science workflows (e.g., CRISP-DM)

Importance of iteration and experimentationRole of computational notebooks in supporting data scienceworkflows

Overview of so�ware engineering processes and lifecycles: costs andbenefits of process, common process models, role of iteration andexperimentationContrasting data science and so�ware engineering processes, goals andconflictsIntegrating data science and so�ware engineering workflows in processmodel for engineering AI-enabled systems with ML and non-MLcomponents; contrasting different kinds of AI-enabled systems with datascience trajectoriesOverview of technical debt as metaphor for process management; commonsources of technical debt in AI-enabled systems

1 . 2

CASE STUDY: REAL-ESTATE WEBSITECASE STUDY: REAL-ESTATE WEBSITE

2 . 1

ML COMPONENT: PREDICTING REAL ESTATE VALUEML COMPONENT: PREDICTING REAL ESTATE VALUEGiven a large database of house sales and statistical/demographic data from

public records, predict the sales price of a house.

f(size, rooms, tax, neighborhood, . . . ) → price

2 . 2

DATA SCIENCE: ITERATIONDATA SCIENCE: ITERATIONAND EXPLORATIONAND EXPLORATION

3 . 1

DATA SCIENCE IS ITERATIVE AND EXPLORATORYDATA SCIENCE IS ITERATIVE AND EXPLORATORY

(Source: Guo. " ." Blog@CACM,Oct 2013)

Data Science Workflow: Overview and Challenges

3 . 2

DATA SCIENCE IS ITERATIVE AND EXPLORATORYDATA SCIENCE IS ITERATIVE AND EXPLORATORY

Martínez-Plumed et al. "." IEEE Transactions on Knowledge and Data

Engineering (2019).

CRISP-DM Twenty Years Later: From Data MiningProcesses to Data Science Trajectories

3 . 3

DATA SCIENCE IS ITERATIVE AND EXPLORATORYDATA SCIENCE IS ITERATIVE AND EXPLORATORY

(Microso� Azure Team, " " Microso�Documentation, Jan 2020)What is the Team Data Science Process?

3 . 4

DATA SCIENCE IS ITERATIVE AND EXPLORATORYDATA SCIENCE IS ITERATIVE AND EXPLORATORY

Source: Patel, Kayur, James Fogarty, James A. Landay, and Beverly Harrison." ." In

Proc. CHI, 2008.Investigating statistical machine learning as a tool for so�ware development

3 . 5

This figure shows the result from a controlled experiment in which participants had 2 sessions of 2h each to build amodel. Whenever the participants evaluated a model in the process, the accuracy is recorded. These plots show theaccuracy improvements over time, showing how data scientists make incremental improvements through frequentiteration.

Speaker notes

DATA SCIENCE IS ITERATIVE AND EXPLORATORYDATA SCIENCE IS ITERATIVE AND EXPLORATORYScience mindset: start with rough goal, no clear specification, unclearwhether possibleHeuristics and experience to guide the processTry and error, refine iteratively, hypothesis testingGo back to data collection and cleaning if needed, revise goals

3 . 6

SHARE EXPERIENCE?SHARE EXPERIENCE?

3 . 7

DIFFERENT TRAJECTORIESDIFFERENT TRAJECTORIES

Martínez-Plumed et al. "." IEEE Transactions on Knowledge and Data

Engineering (2019).

CRISP-DM Twenty Years Later: From Data MiningProcesses to Data Science Trajectories

3 . 8

DIFFERENT TRAJECTORIESDIFFERENT TRAJECTORIES

From: Martínez-Plumed et al. "." IEEE Transactions on Knowledge and Data

Engineering (2019).

CRISP-DM Twenty Years Later: From Data MiningProcesses to Data Science Trajectories

3 . 9

A product to recommend trips connecting tourist attractions in a town may be based on location tracking datacollected by navigation and mapping apps. To build such a project, one might start with a concrete goal in mindand explore whether enough user location history data is available or can be acquired. One would then gothrough traditional data preparation and modeling stages before exploring how to best present the results tousers.An insurance company tries to improve their model to score the risk of drivers based on their behavior andsensors in their cars. Here an existing product is to be refined and a better understanding of the business case isneeded before diving into the data exploration and modeling. The team might spend significant time in exploringnew data sources that may provide new insights and may debate the cost and benefits of this data or datagathering strategy (e.g., installing sensors in customer cars).A credit card company may want to sell data about what kind of products different people (nationalities) tend tobuy at different times and days in different locations to other companies (retailers, restaurants). They mayexplore existing data without yet knowing what kind of data may be of interest to what kind of customers. Theymay actively search for interesting narratives in the data, posing questions such as “Ever wondered when theFrench buy their food?” or “Which places the Germans flock to on their holidays?” in promotional material.

Speaker notes

COMPUTATIONAL NOTEBOOKSCOMPUTATIONAL NOTEBOOKS

Origins in "literate programming",interleaving text and code, treatingprograms as literature (Knuth'84)First notebook in WolframMathematica 1.0 in 1988Document with text and code cells,showing execution results undercellsCode of cells is executed, per cell,in a kernelMany notebook implementationsand supported languages, Python+ Jupyter currently most popular

3 . 10

See also Demo with public notebook, e.g.,

Speaker notes

https://en.wikipedia.org/wiki/Literate_programminghttps://colab.research.google.com/notebooks/mlcc/intro_to_pandas.ipynb

NOTEBOOKS SUPPORT ITERATION ANDNOTEBOOKS SUPPORT ITERATION ANDEXPLORATIONEXPLORATION

Quick feedback, similar to REPLVisual feedback including figures and tablesIncremental computation: reexecuting individual cellsQuick and easy: copy paste, no abstraction neededEasy to share: document includes text, code, and results

3 . 11

BRIEF DISCUSSION: NOTEBOOK LIMITATIONS ANDBRIEF DISCUSSION: NOTEBOOK LIMITATIONS ANDDRAWBACKS?DRAWBACKS?

3 . 12

SOFTWARE ENGINEERINGSOFTWARE ENGINEERINGPROCESSPROCESS

4 . 1

INNOVATIVE VS ROUTINE PROJECTSINNOVATIVE VS ROUTINE PROJECTSLike data science tasks, most so�ware projects are innovative

Google, Amazon, Ebay, NetflixVehicles and roboticsLanguage processing, Graphics, AI

Routine (now, not 20 years ago)E-commerce websites?Product recommendation? Voice recognition?Routine gets automated -> innovation cycle

4 . 2

A SIMPLE PROCESSA SIMPLE PROCESS1. Discuss the so�ware that needs to be written2. Write some code3. Test the code to identify the defects4. Debug to find causes of defects5. Fix the defects6. If not done, return to step 1

4 . 3

SOFTWARE PROCESSSOFTWARE PROCESS

Examples?

“The set of activities and associated results that produce aso�ware product”

4 . 4

Writing down all requirements Require approval for all changes to requirements Use version control for all changesTrack all reported bugs Review requirements and code Break down development into smaller tasks and schedule andmonitor them Planning and conducting quality assurance Have daily status meetings Use Docker containers to pushcode between developers and operation

Speaker notes

4 . 5

Visualization following McConnell, Steve. Software project survival guide. Pearson Education, 1998.

Speaker notes

4 . 6

Idea: spent most of the time on coding, accept a little rework

Speaker notes

4 . 7

negative view of process. pure overhead, reduces productive work, limits creativity

Speaker notes

4 . 8

Real experience if little attention is payed to process: increasingly complicated, increasing rework; attempts to rescue byintroducing process

Speaker notes

EXAMPLE OF PROCESS PROBLEMS?EXAMPLE OF PROCESS PROBLEMS?

4 . 9

Collect examples of what could go wrong:

Change Control: Mid-project informal agreement to changes suggested by customer or manager. Project scope expands25-50% Quality Assurance: Late detection of requirements and design issues. Test-debug-reimplement cycle limitsdevelopment of new features. Release with known defects. Defect Tracking: Bug reports collected informally, forgottenSystem Integration: Integration of independently developed components at the very end of the project. Interfaces out ofsync. Source Code Control: Accidentally overwritten changes, lost work. Scheduling: When project is behind,developers are asked weekly for new estimates.

Speaker notes

TYPICAL PROCESS STEPS (NOT NECESSARILY INTYPICAL PROCESS STEPS (NOT NECESSARILY INTHIS ORDER)THIS ORDER)

Understand customers, identify what to build, by when, budgetIdentify relevant qualities, plan/design system accordinglyTest, deploy, maintain, evolvePlan, staff, workaround

4 . 10

SURVIVAL MODESURVIVAL MODEMissed deadlines -> "solo development mode" to meet own deadlinesIgnore integration workStop interacting with testers, technical writers, managers, ...

4 . 11

Hypothesis: Process increases flexibility and efficiency + Upfront investment forlater greater returns

4 . 12

ideal setting of little process investment upfront

Speaker notes

4 . 13

Empirically well established rule: Bugs are increasingly expensive to fix the larger the distance between the phasewhere they are created vs where they are corrected.

Speaker notes

4 . 14

Complicated processes like these are often what people associate with "process". Software process is needed, but doesnot need to be complicated.

Speaker notes

SOFTWARE PROCESSSOFTWARE PROCESSMODELSMODELS

5 . 1

AD-HOC PROCESSESAD-HOC PROCESSES1. Discuss the so�ware that needs to be written2. Write some code3. Test the code to identify the defects4. Debug to find causes of defects5. Fix the defects6. If not done, return to step 1

5 . 2

WATERFALL MODELWATERFALL MODEL

taming the chaos, understand requirements, plan before coding, remember testing

( )CC-BY-SA-2.5

5 . 3

Although dated, the key idea is still essential -- think and plan before implementing. Not all requirements and design canbe made upfront, but planning is usually helpful.

Speaker notes

RISK FIRST: SPIRAL MODELRISK FIRST: SPIRAL MODEL

1.Determineobjectives

2. Identify and resolve risks

3. Development and Test

4. Plan the next iteration

ProgressCumulative cost

Requirementsplan

Concept ofoperation

Concept ofrequirements

Prototype 1 Prototype 2Operationalprototype

Requirements DraftDetaileddesign

Code

IntegrationIntegration

Test

Implementation

Release

Test plan Verification & Validation

Developmentplan

Verification & Validation

Review

incremental prototypes, starting with most risky components

5 . 4

CONSTANT ITERATION: AGILECONSTANT ITERATION: AGILE

30 days

24 h

Working incrementof the software

Sprint Backlog SprintProduct Backlog

working with customers, constant replanning

(CC BY-SA 4.0, Lakeworks)

5 . 5

CONTRASTING PROCESS MODELSCONTRASTING PROCESS MODELSAd-hoc -- Waterfall -- Spiral -- Agile

5 . 6

DATA SCIENCE VSDATA SCIENCE VSSOFTWARE ENGINEERINGSOFTWARE ENGINEERING

6 . 1

DISCUSSION: ITERATION IN NOTEBOOK VS AGILE?DISCUSSION: ITERATION IN NOTEBOOK VS AGILE?

30 days

24 h

Working incrementof the software

Sprint Backlog SprintProduct Backlog

(CC BY-SA 4.0, Lakeworks)

6 . 2

There is similarity in that there is an iterative process, but the idea is different and the process model seems mostlyorthogonal to iteration in data science. The spiral model prioritizes risk, especially when it is not clear whether a model isfeasible. One can do similar things in model development, seeing whether it is feasible with data at hand at all and buildan early prototype, but it is not clear that an initial okay model can be improved incrementally into a great one later. Agilecan work with vague and changing requirements, but that again seems to be a rather orthogonal concern. Requirementson the product are not so much unclear or changing (the goal is often clear), but it's not clear whether and how a modelcan solve it.

Speaker notes

POOR SOFTWARE ENGINEERING PRACTICES INPOOR SOFTWARE ENGINEERING PRACTICES INNOTEBOOKS?NOTEBOOKS?

*

Little abstractionGlobal stateNo testingHeavy copy and pasteLittle documentationPoor version controlOut of order executionPoor development features (vs IDE)

6 . 3

UNDERSTANDING DATA SCIENTIST WORKFLOWSUNDERSTANDING DATA SCIENTIST WORKFLOWSInstead of blindly recommended "SE Best Practices" understand contextDocumentation and testing not a priority in exploratory phaseHelp with transitioning into practice

From notebooks to pipelinesSupport maintenance and iteration once deployedProvide infrastructure and tools

6 . 4

DataScientists

SoftwareEngineers

6 . 5

DATA SCIENCE PRACTICES BY SOFTWAREDATA SCIENCE PRACTICES BY SOFTWAREENGINEERSENGINEERS

Many so�ware engineers get involved in data science without explicittrainingCopying from public examples, little reading of documentationLack of data visualization/exploration/understanding, no focus on dataqualityStrong preference for code editors, non-GUI toolsImprove model by adding more data or changing models, rarely featureengineering or debuggingLack of awareness about overfitting/bias problems, single focus onaccuracy, no monitoringMore system thinking about the product and its needs

6 . 6

INTEGRATED PROCESS FORINTEGRATED PROCESS FORAI-ENABLED SYSTEMSAI-ENABLED SYSTEMS

7 . 1

Figure from Dogru, Ali H., and Murat M. Tanik. “A process model for component-oriented so�ware engineering.”IEEE So�ware 20, no. 2 (2003): 34–41.

7 . 2

7 . 3

7 . 4

7 . 5

7 . 6

7 . 7

PROCESS FOR AI-ENABLED SYSTEMSPROCESS FOR AI-ENABLED SYSTEMSIntegrate So�ware Engineering and Data Science processesEstablish system-level requirements (e.g., user needs, safety, fairness)Inform data science modeling with system requirements (e.g., privacy,fairness)Try risky parts first (most likely include ML components; ~spiral)Incrementally develop prototypes, incorporate user feedback (~agile)Provide flexibility to iterate and improveDesign system with characteristics of AI component (e.g., UI design,safeguards)Plan for testing throughout the process and in productionManage project understanding both so�ware engineering and data scienceworkflows

No existing "best practices" or workflow models

7 . 8

TRAJECTORIESTRAJECTORIESNot every project follows the same development process, e.g.

Small ML addition: Product first, add ML feature laterResearch only: Explore feasibility before thinking about a productData science first: Model as central component of potential product,build system around it

Different focus on system requirements, qualities, and upfront planningManage interdisciplinary teams and different expectations

7 . 9

7 . 10

TECHNICAL DEBTTECHNICAL DEBT

8 . 1

TECHNICAL DEBT METAPHORTECHNICAL DEBT METAPHORAnalogy to financial debt

Have a benefit now (e.g., progress quickly, release now)accepting later cost (loss of productivity, e.g., highermaintenance/operating cost, rework)debt accumulates and can suffocate project

Ideally a deliberate decision (short term tactical or long term strategic)Ideally track debt and plan for paying it down

Examples?

8 . 2

Source: Martin Fowler 2009,https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

8 . 3

TECHNICAL DEBT FROM ML COMPONENTS?TECHNICAL DEBT FROM ML COMPONENTS?

(see reading)

Sculley, David, et al. . Advances in Neural InformationProcessing Systems. 2015.

Hidden technical debt in machine learning systems

8 . 4

THE NOTEBOOKTHE NOTEBOOK

Jupyter Notebooks are a gi� from God to those who workwith data. They allow us to do quick experiments with

Julia, Python, R, and more -- John Paul Ada

8 . 5

Discuss benefits and drawbacks of Jupyter style notebooks

Speaker notes

ML AND TECHNICAL DEBTML AND TECHNICAL DEBTO�en reckless and inadvertent in inexperienced teamsML can seem like an easy addition, but it may cause long-term costsNeeds to be maintained, evolved, and debuggedGoals may change, environment may change, some changes are subtle

Example problemsSystems and models are tangled and changing one has cascadingeffects on the otherUntested, brittle infrastructure; manual deploymentUnstable data dependencies, replication crisisData dri� and feedback loopsMagic constants and dead experimental code paths

Further reading: Sculley, David, et al. . Advances in NeuralInformation Processing Systems. 2015.

Hidden technical debt in machine learning systems

8 . 6

CONTROLLING TECHNICAL DEBT FROM MLCONTROLLING TECHNICAL DEBT FROM MLCOMPONENTSCOMPONENTS

8 . 7

CONTROLLING TECHNICAL DEBT FROM MLCONTROLLING TECHNICAL DEBT FROM MLCOMPONENTSCOMPONENTS

Avoid AI when not neededUnderstand and document requirements, design for mistakesBuild reliable and maintainable pipelines, infrastructure, good engineeringpracticesTest infrastructure, system testing, testing and monitoring in productionTest and monitor data qualityUnderstand and model data dependencies, feedback loops, ...Document design intent and system architectureStrong interdisciplinary teams with joint responsibilitiesDocument and track technical debt...

8 . 8

8 . 9

SUMMARYSUMMARYData scientists and so�ware engineers follow different processesML projects need to consider process needs of bothIteration and upfront planning are both important, process models codifygood practicesDeliberate technical debt can be good, too much debt can suffocate aprojectEasy to amount (reckless) debt with machine learning

9

FURTHER READINGFURTHER READING

� Sculley, David, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips,Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, andDan Dennison. " ." InAdvances in neural information processing systems, pp. 2503-2511. 2015.� Studer, Stefan, Thanh Binh Bui, Christian Drescher, Alexander Hanuschkin,Ludwig Winkler, Steven Peters, and Klaus-Robert Mueller. "

." arXiv preprint arXiv:2003.05155 (2020).� Martínez-Plumed, Fernando, Lidia Contreras-Ochando, Cesar Ferri, JoséHernández Orallo, Meelis Kull, Nicolas Lachiche, Maréa José RamírezQuintana, and Peter A. Flach. "

." IEEE Transactions onKnowledge and Data Engineering (2019).

On the process for building so�ware with ML components

Hidden technical debt in machine learning systems

Towards CRISP-ML (Q): A Machine Learning Process Model with Quality AssuranceMethodology

CRISP-DM Twenty Years Later: From DataMining Processes to Data Science Trajectories

10 . 1

17-445 So�ware Engineering for AI-Enabled Systems, Christian Kaestner

FURTHER READING 2FURTHER READING 2� Patel, Kayur, James Fogarty, James A. Landay, and Beverly Harrison."

." In Proceedings of the SIGCHI Conference on Human Factorsin Computing Systems, pp. 667-676. 2008.� Yang, Qian, Jina Suh, Nan-Chen Chen, and Gonzalo Ramos. "

." In Proceedings of the 2018 Designing Interactive Systems Conference,pp. 573-584. 2018.📰 Fowler and Highsmith. � Steve McConnell. So�ware project survival guide. Chapter 3� Pfleeger and Atlee. So�ware Engineering: Theory and Practice. Chapter 2� Kruchten, Philippe, Robert L. Nord, and Ipek Ozkaya. "

." IEEE So�ware 29, no. 6 (2012): 18-21.

Investigating statistical machine learning as a tool for so�waredevelopment

Groundinginteractive machine learning tool design in how non-experts actually buildmodels

The Agile Manifesto

Technical debt:From metaphor to theory and practice

10 . 2