This is perhaps an example of the hazard of metaphor: it can encourage inaccurate or even misleading analogic reasoning. The theme of technical debt is intertwined with organizational issues. Accounting for tech debt is not done at an organizational level, it's done on a team or individual level. The organization has little idea of how much technical debt it 'carries' in its code and paying tech debt is notoriously difficult to make visible to those setting business level priorities. There is an expectation that technical debt will be managed locally, with individuals and teams devoting just enough effort to keep the debt low while still keeping the velocity of development high. Critically, technical debt is, by definition, appreciated prior to its creation, visible in code, and can be eliminated by refactoring.

„Slow is smooth and smooth is fast.“

Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study.

As of right now the full build takes over an hour to run, and this makes cycling for PRs and quick iterative development very difficult.

Kommt ein Teil der Angst nicht auch aus der Furcht vor Fehlern? Oft funktioniert die Software eben doch nicht so gut wie die Bremsen meines Autos. Der Computer beruht auf den gleichen einfachen Prinzipien wie vor sechzig Jahren. Aber die Leistungsfähigkeit hat sich millionenfach gesteigert. Der Effekt dieser Leistungssteigerung auf die Programmierung ist allerdings sehr negativ – vor allem auf die Disziplin der Programmierung. Früher waren die Ressourcen extrem begrenzt, heute dagegen ist alles in Unmengen vorhanden: Speicher, Rechenleistung, Übertragungskapazitäten, einfach alles. Niemand muss mehr sparen. Programmieren heißt aber, Disziplin zu bewahren und jeden Moment darauf zu achten, dass man unnötige Komplexität vermeidet. Dieses Denken verschwindet mehr und mehr. Denn eine solche Optimierung erfordert Zeit. Sie wäre viel teurer, als einfach noch ein bisschen Hardware dazuzukaufen. Deswegen wird es nicht gemacht. Anzeige Warum ist das schlimm? Diese schnell erstellten Programme sind nicht nur weniger ökonomisch. Sie enthalten auch mehr Fehler.

“If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.” -- Albert Einstein

Why does test suite performance matter? First of all, testing is a part of a developer's feedback loop (see @searls talk) and, secondly, it is a part of a deployment cycle.