Did you notice how everything in IT is crap right now? Basic apps demand absurd amounts of memory, updates remove features people actually use, and moving a button counts as innovation; add a chatbot and there's a keynote. When Facebook was bragging about breaking things, at least it was to move faster. What's the excuse now?

And when somebody finally tries to fix the mess, they inherit years of decisions nobody can explain. Why does this ugly workaround exist, and is it safe to remove? The code is in Git, the ticket says "done", and the explanation left during the last reorg, so good luck with the refactoring.

Baruch will examine how we get here: incentives that reward shipping over maintaining, reorganizations that scatter responsibility, and technical decisions that outlive everybody who understood them. Each change can look reasonable on its own while making the whole system worse. We call the result technical debt, but a backlog of cleanup tickets won't recover the knowledge we've lost. LLMs love adding documentation to the pile, which looks helpful until finding the answer buried in it becomes as hard as finding the colleague who left.

Baruch will discuss what it takes to keep the reasons behind architectural decisions available to the next developer, along with who owns the service and what depends on it. Someone has to keep that knowledge current and retire what's obsolete, so finding an answer doesn't require an archaeological expedition through generated Markdown.

Fixing the Googles and Metas may be beyond the reach of a conference talk, but there's still time to stop your own project from providing material for the next one.

This talk connects familiar software decay to the incentives and missing decision history that make maintenance difficult. Developers and engineering leaders get a way to examine why their own systems are deteriorating, including what the next maintainer needs to know before removing an ugly workaround.