Two comments: 1. When things don't line up like the plans in an analog project, you can just "line them up" and the original intent isn't seriously disturbed.

Two comments: 1. When things don't line up like the plans in an analog project, you can just "line them up" and the original intent isn't seriously disturbed. That doesn't work in a hard-logic digital world. 2. That said, "real" projects still can come together more quickly because they are better about using interfaces and being loosely coupled than we (software developers) are. You can slightly move joists, light switches, etc, because the interfaces of how they interact with other components are better defined, and the glue code (ie wires, nails, cuts) can be trivially adjusted to make things fit and still get the desired end outputs. #2 is partly why software "integration" projects can be hacky as hell and still work, they're just glue code for clearly defined interfaces. If we designed our internal applications with such simplicity and clearly-defined interfaces and wired them together rather than coupling them, it'd be more predictable. Unfortunately that's really tough to do for software inventions, as there are so many new things where the interfaces might not even be able to be clearly defined. Construction would look a lot more like software if you ordered wood but when the stack of wood showed up it was metal rods instead, or if it came pre-molded to the shape of another house. There are just too many variables in de novo software. I used to have this debate with my old boss all the time. You either live with the reality and create new, valuable stuff, or if you want to build bridges, go write glue code for legacy systems.