[00:02] 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
[00:15] 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
[00:31] 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
[00:46] 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
[00:59] 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
[01:17] 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
[01:32] 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
[01:44] 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
[01:59] 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
[02:11] 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
[02:23] 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
[02:38] 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
[02:54] 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
[03:09] 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
[03:21] 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
[03:37] splitting up a program and creating predictable points of interface like all engineering it is the catastrophic failures that have provided the impulse
[03:51] to change and build systems that are more robust