ML vs. Traditional Software Modularity

Overview

Traditional software engineering relies on modularity, separating components so developing one doesn’t interfere with others. ML systems resist this pattern in fundamental ways.

Traditional Software Modularity

Characteristic	How It Works
Boundaries	Modules interact only through defined APIs
Independence	One component’s behavior doesn’t change based on another’s implementation
Conway’s Law	Team structure mirrors system architecture; separate modules → separate teams
Extensibility	Add functionality by adding new modules
Composition	Combine modules predictably (A + B = A+B)

ML System (Lack of) Modularity

Characteristic	How It Differs
Entanglement	Models affect each other during training even when code is separate
Hidden dependencies	Changes to one model degrade another through non-obvious pathways
Team coupling	Separate teams must collaborate closely regardless of code separation
Non-extensibility	Can’t easily add capabilities by combining models (English NLP + pizza ordering ≠ pizza-ordering NLP)
Non-monotonic composition	Improving one part can make the whole worse

Key Differences Summarized

Dimension	Traditional Software	ML Systems
Unit of composition	Functions, modules, libraries	Models, data, features
Change propagation	Explicit through APIs	Implicit through learned dependencies
Testing	Unit tests verify isolation	System tests required; unit tests insufficient
Reuse	Fork, modify, integrate	Retrain, often from scratch
Skills for customization	Same as development	Requires ML expertise + domain data

When This Matters

• System architecture decisions (can’t assume module boundaries hold)
• Team organization (Conway’s Law may not apply)
• Technical debt estimation (entanglement accelerates debt)
• Testing strategy (component tests give false confidence)
• Change impact analysis (improvements can cause regressions)

The Implication

ML systems require different engineering patterns than traditional software. Treating ML components like regular modules creates hidden risks that surface in production.

Related: 05-atom—model-entanglement, 05-atom—non-monotonic-error-propagation