The Iceberg of 'Working' Software
Description
A black-and-white cartoon illustrating the iceberg meme format applied to software development. The image is divided by a water line. Above the water, the visible tip of an iceberg is labeled 'Working Software' under the heading 'WHAT YOU SEE.' Below the water, the much larger, submerged part of the iceberg is labeled 'WHAT YOU DON'T SEE' and has arrows pointing to various sections, each describing a hidden problem or sacrifice. These descriptions are: 'The jar files that Vivek, the sys-admin, copied into the cluster to hot-fix the production release that brought down the web site.', 'The weekend that Megan, the Senior Developer, spent fixing code that Jerry, the Junior Developer, left behind when he quit in a huff.', 'The family meal that Beth, the SRE, missed having to work late to reconcile the CI/CD pipeline with the hot-fix Vivek made.', and 'The 3 hour argument that the dev-lead had with the product manager trying to avoid corrupting the app's API.' The cartoon effectively visualizes the immense, unseen effort, compromises, and human cost required to keep software running, which is often invisible to outsiders or management
Comments
7Comment deleted
They call it 'working software' because the alternative, 'a fragile coalition of last-minute hacks, weekend heroics, and a looming API disaster held off by one very tired dev lead,' doesn't fit neatly on a status report
Sure, it’s ‘just a simple feature’ - right up until your iceberg backlog melts all over the SRE’s Friday night
The real iceberg is discovering that Vivek's jar file hotfix from 2019 is now load-bearing infrastructure that three microservices depend on, and removing it triggers a cascade failure that somehow affects the billing system
The iceberg perfectly captures what every architect knows: 'working software' is just the tip - beneath lies a Mariana Trench of emergency hotfixes, CI/CD pipeline archaeology, junior dev code that's now your problem, and three-hour API design debates that could've been resolved with a RFC. The real kicker? Stakeholders only see the tip and wonder why estimates are always 'too high.'
Behind every “it works in prod” moment is an scp’d JAR, a canceled SRE dinner to rewire CI/CD, a weekend of code archaeology, and three hours of API governance to dodge versioning purgatory
Uptime was just eventual consistency between 'scp jar to cluster' and a three-hour API treaty with the PM
Hotfixes deliver availability at the cost of team consistency - CAP theorem hits the SRE roster harder than any cluster