---
title: 'Software Development''s Biggest Failure Was Its Most Influential'
source: 'https://youtube.com/watch?v=KV5I30HDRd8'
video_id: 'KV5I30HDRd8'
date: 2026-07-31
duration_sec: 235
---

# Software Development's Biggest Failure Was Its Most Influential

> Source: [Software Development's Biggest Failure Was Its Most Influential](https://youtube.com/watch?v=KV5I30HDRd8)

## Summary

This video explores why early software development projects often failed catastrophically, using IBM's OS/360 as the canonical example. It explains the 'death spiral' of bug-fixing, why adding developers made things worse, and how these failures shaped modern practices like small teams, stand-up meetings, and modular programming.

### Key Points

- **Catastrophic early projects** [00:02] — Many early software projects failed badly; IBM's OS/360 is the canonical example. Such failures happened repeatedly until the industry learned to fix them.
- **The death spiral** [00:15] — Failing projects entered a death spiral: every bug fix introduced on average 1.5 new bugs, making the code progressively worse despite debugging efforts.
- **Management's counterproductive fix** [00:59] — Faced with missed deadlines and worsening code, management hired more developers—which made everything worse.
- **Why adding developers backfires** [01:17] — New developers must be trained, consuming time of existing developers. Plus, coordination overhead grows, eventually causing a net reduction in programming output.
- **Interdependency nightmare** [02:11] — Early programs allowed any part to access any other part, creating massive interdependencies. A change anywhere could affect anything, and it was impossible to predict where.
- **Small teams and stand-ups** [02:38] — Modern developers work in small teams of 3–5 and hold daily stand-up meetings to coordinate what each person will do, easing coordination issues.
- **Modular design and paradigms** [03:09] — Programs are split into small components with restricted interactions, so changes have limited, predictable effects. Structured, object-oriented, and functional programming are different styles of achieving this.
- **Failure drives progress** [03:37] — Like all engineering, catastrophic failures provided the impulse to change and build more robust systems.

## Transcript

development there were some catastrophically bad projects while we catastrophically bad projects while we normally take IBM's OS 360 as the canonical example this failure happened over and over again until we worked out
how to fix these project entered what could only be described as a death spiral they had bugs all software has bugs that is completely normal in fact some people consider the act of programming just as debugging so at the
because it just doesn't work and then you slowly remove bugs until you get a working program as I say that's a normal part of programming normally what you do is you write code you test that code you discover bugs in that code you correct
them and you go in a cycle and you can continue that cycle until you have something you can deliver but what happened in these projects is every time they corrected a bug the change to fix the bug would introduce on average one
and a half bags somewhere else in the project so the code was getting progressively worse faced with a project that was missing deadlines and looking increasingly more problematic management swung in with their fix they hired more
swung in with their fix they hired more developers this made everything worse why every software project is different the point of software development is to write something new so whenever you add a new person onto your project you have
to induct and train them to understand what the current code base has getting a new member up to speed is something that takes time out of every other dev's time
budget however there's a more Insidious problem each developer has to coordinate with their workmates so they don't end up stepping on each other's toes when they're making changes to the code there is a point at which adding a new Dev
will result in a net reduction of the amount of programming that is done just because of the overhead of coordination this scaling issue is also related to
why these early programming projects had so many problems before we knew better every part of a computer program could have free range and access any other
part of the same program it kind of made sense why would you put up barriers sense why would you put up barriers inside of the program but what it meant was there was a huge amount of interdependency between every part of
the program any alteration you made at one point could affect any other part and it was impossible to know where these independent dependencies were so how would these problems fixed devs now work in very small teams three to five
is about the typical size of a team every day we'll have short stand-up meetings where you will go over what you'll be doing which helps with the coordination issues we also changed how programs are designed and built programs
are split up into small components and we restrict the possible interactions between the components to be a limited number so a change in one place has a
limited and predictable outcomes on other places in the code structured procedural programming object oriented programming functional programming and whatever you call the thing that rust does are just different styles of
splitting up a program and creating predictable points of interface like all engineering it is the catastrophic failures that have provided the impulse
to change and build systems that are more robust