Your phrasing suggests a comparison between 1. a finished building and 2. the process of making a piece of software.. of course there is no comparison. If you

Your phrasing suggests a comparison between 1. a finished building and 2. the process of making a piece of software.. of course there is no comparison. If you look at a more apples to apples comparison, ie. designing (and in that I would include designing the process of building) a bespoke building. Designing a building is about structuring a building process, a business process, a living process, a manufacturing process, or public interface, a place of work, or life, or learning or wonder, all within or about the confines of a building. Even simple bespoke buildings bring together hundreds of thousands or even millions of parts which have never been put together in this way or by these particular people before. You have to consider how all these materials fit together, behave together, how they degrade over time, their warranties, their performance, how they will get removed, replaced, disposed of. You have to consider how buildings will be modified, or inhabited or changed over time (because if you can't change it, it will be knocked down). You have to account for the wildly differing preferences for taste, or comfort, or usage of buildings which your clients cannot describe and often have no awareness of. Your client is sometimes the end user, but most end users are not clients. You have no control over any of the important decision making processes, but lots of control over the unimportant ones. All of your attempts to standardise the process in order to contain timeframes result in an incremental lessening of quality or usefulness - sometimes to the effect that the finished product horribly underserves the end users (you often make the clients happy though). Clients also sometimes just refuse to pay. Architects have been thinking about and writing about and experimenting with information gathering, processing and dissemination for (at least) hundreds of years. I mean, architects were knowledge workers before we even had paper to draw the blueprints on. Much of the early systems of standardisation and automation were driven by architecture (and fashion surely). Hell, the first 3D scanning of an object, a statue, was in the 15thC by an architect.[0] We have been using ticket systems ( rfis), bug reports (post occupation evaluation) and version control systems (transmittals and revisions) for longer than the software industry has been around. The reason for all the arcane processes in the industry is to try to capture, use and re-use information. To standardise processes across consultants, builders, clients, and manufacturers. Most architects are shit, we developed horrible hiring procedures to weed out the shit ones, that don't really work. They chronically underpay staff. They have missed just as many deadlines, and spent just as much money in cost blowouts as the software industry. No. Designing buildings is almost exactly like designing software. It is just data processing and prediction after all.. and bullshit. Everything new is old. You can probably learn from their mistakes. [0] https://www.smithsonianmag.com/arts-culture/digital-files-and-3d-printingin-the-renaissance-244207/ https://www.smithsonianmag.com/arts-culture/digital-files-an...