One essential part is managing complexity. With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering g

One essential part is managing complexity. With a mechanical part it often is obvious to see and easy to understand what this part does. A lot of engineering goes into finding the right materials, the best shape and processing tools. But the finished part is easy to understand. With software engineering we have abstractions like "sort algorithm" that are easy to understand but many things have so many cross-connections to other parts that in order to understand what is actually going on you have to get really deep into this stuff. Changing a detail in one implementation may lead to unforseen consequences on other, seemingly unrelated, parts. You may rely on undocumented features without even knowing that. How many cables do you see when you cut a boeing in half? How many of them are essential to operating the plane? How many dangling pointers do you get if you cut your main memory in half? How many of them are of system components? Whatever technique we have to cut down complexity, hide implementation details behind clear interfaces, separating stuff into easily-to-combine modules makes managing projects easier. I think that the main success factor of python lies in this area. Then imagine a project that does not have all those modules readily available. That does not have engineers who know it all (and really do, not just pretend) in charge. They rough out a plan and start working on many ends that - when they meet - do not fit together. Add in organizational, personal, psychological problems and the structure wraps in on itself, turns on itself in infighting about how-to-do-stuff, career postions, blame, praise, just surviving or just passively standing by fulfilling orders on paper waiting until everything collapses.