Dependency Hell — "It Works on My Machine"

The five words every engineer dreads

"It works on my machine." The universal admission that environments diverge — and that hours just got burned chasing a bug that has nothing to do with your code.

The technical name for this is dependency hell: your app needs Python 3.12, staging has 3.10. Your node_modules install differently on macOS vs Linux. libssl and libpq versions drift across hosts. Every new hire spends two days getting their laptop to match production.

Why this is expensive

Engineering time — the most expensive resource — leaks into reproducing setups instead of shipping features.
Onboarding stretches from hours to days because there is no canonical environment.
Deploy failures become normal: code that passed CI breaks in prod because the host's libc is different.
Rollbacks are scary because you cannot perfectly recreate the previous environment.

What containers fix

A container packages your process, its filesystem assumptions, and its OS-level dependencies into a single artifact. The same artifact runs on your laptop, on CI, on staging, on production. Different host kernel? Same artifact. Different cloud? Same artifact. The image is the contract.

This is not just convenience — it is a shift in what counts as the deliverable. The deliverable is no longer "source code plus a wiki page about how to run it." It is the image.

Code

The classic divergence·bash

# Your laptop
python --version
# Python 3.12.2

# Staging server (set up 14 months ago)
ssh staging 'python --version'
# Python 3.10.7

# CI runner (default image)
echo 'python --version' | docker run --rm -i python:3.11-slim sh
# Python 3.11.10

# Three machines, three Pythons. The bug that 'only happens in staging'
# is almost always the gap between these lines.

Same artifact, three hosts·bash

# Build once
docker build -t myapp:1.0 .

# Run on your laptop
docker run --rm myapp:1.0

# Run on staging (same image, pulled from registry)
ssh staging 'docker run --rm registry.example.com/myapp:1.0'

# Run in CI
# (CI just pulls and runs the same tag)

# All three executions use byte-identical layers.
# 'Works on my machine' becomes a nonsensical complaint.

Exercise

Pick a real project on your machine. List every dependency that a teammate would need to install to run it: Python/Node version, OS libraries, env vars, services (Postgres, Redis), tools (ffmpeg, curl). How long would onboarding take from a fresh laptop? Then describe — in two sentences — how a Dockerfile would replace that list.