Plans should ship like software.
Who This Matters To (And Why)
Critical: Architect,GC,Developer. These parties make or lose money directly based on this thesis.
Important: Engineer,Banker,City. These parties execute decisions shaped by this thesis.
Context: Investor,Inspector,Interior Design. These parties need to understand it to avoid friction.
Highest typology impact: Multifamily,Office,Industrial,Mixed Use. Lower impact: Hotel,Retail.
Plans should ship like software: versioned, tested, and continuously improved.
How It Shapes Development
Plans should ship like software because the construction document is a release, not a final product, and the building it produces will require patches, updates, and version management throughout its operating life. Software ships in versions: 1.0 at initial release, 1.1 with bug fixes, 2.0 with major feature additions. Buildings ship in phases: permit set, issued for construction, addenda, change orders, record documents. The process is the same. The vocabulary is different. And critically, software development has developed rigorous practices for managing releases that construction has not.
Continuous delivery in construction is possible and underutilized. In software, continuous delivery means releasing small, frequent updates rather than large, infrequent ones. In construction, the equivalent is fast-track delivery: begin foundation construction while superstructure design is still underway, release shop drawings in packages rather than waiting for full permit approval, allow the contractor to begin procurement before construction documents are fully issued. Each early release reduces schedule risk by moving the critical path earlier. The risk is managing the interfaces between packages. Fast-track delivery is continuous delivery with a concrete pump.
Bug reports in construction are RFIs. A request for information is a contractor telling the design team that the documents contain an ambiguity, conflict, or error that prevents construction from proceeding as specified. RFIs are bugs. A project with 800 RFIs has 800 bugs in its documents. A project with 50 RFIs has better documentation quality. Tracking RFI count as a quality metric is the construction equivalent of tracking bug count in software. Low bug count is evidence of quality documentation. High bug count is evidence of insufficient design coordination before release.
Building operating systems are the maintenance releases that follow initial delivery. The building automation system software, the elevator dispatch algorithm, the access control firmware — these are software systems embedded in the physical building that require ongoing updates, security patches, and feature additions. A building delivered in 2015 is running on 2015-era building automation software. By 2025, that software has been superseded by systems with dramatically better energy management capabilities. The building that was designed to allow its operating systems to be updated independently of its physical structure can take advantage of these improvements. The building that embedded its control logic in proprietary hardware cannot.