Buildings are totally different in that they are all, roughly, the same or small variations on the same design. Consequently it is very easy to reuse massive am

Buildings are totally different in that they are all, roughly, the same or small variations on the same design. Consequently it is very easy to reuse massive amounts of reusable components in extremely predictable ways and to define standards for review that can be broadly applied across the majority of projects. This is not the case when builders are doing something that is actually totally novel in that they don't have many existing examples and it is built of entirely custom components. In cases like that it is actually exactly like software in that there is a lot of figuring things out as you go along, schedules are usually laughably off by orders of magnitude, and there are frequently major screw ups (Big dig, Seattle big bertha fiasco, SF Bay Bridge, ... to name a very few) Of course in software we aren't always reinventing everything as people unfairly complain. We reuse way more than we reinvent - postgres, elixir, phoenix, browsers, OSX, etc, etc, etc represent 1000s of lifetimes of work and the majority of the totality of work behind an actual product. The time we do spend, and consequently the variability in schedule, is due to the fact that most software is actually quite different in its requirements from all previous software and usually previous examples (aka competitors) have not made source code available for reuse. One huge difference between software development and "custom" building development is that good software developers embrace this variability and uncertainty - hence agile. Most other fields of engineering are still caught in an archaic and delusional world of gantt charts and hard deadlines with feature lists developed by architects. It never works that way insofar as the work is _custom_ - in any field! The thing I really hate about this conversation is how so many people are so eager to just chalk all this up to software developers being half-assed hacks. Well there are lots of teams at places like HP staffed by only "certified" software engineers and guess what? They still are terrible at predicting outcomes and they are actually far far worst in general at their jobs than small, modern, agile teams who make the best of the chaos by addressing that reality in how they work (again, agile). This is software development people. It isn't about bad devs and lack of certification, it is just hard. For comparison I did integrated circuit design for 7 years right out of school up through being a lead on multiple larger teams before switching to software. The rigor you perceive in other areas of engineering is a total fantasy. Bridges and buildings are maybe the exception but again this is only possible because it is such a canned art by comparison. If you disagree please just enumerate some specific "building codes" or "certification requirements" that you think would actually make any difference on your average complex software project.