#The down side supertall leaks creaks software#

I'm sure I'm not the only one feeling like the current Software Development process is a mess. This comment is more of a rambling than a coherent thought, but I thought I'd get it out there. This doesn't even count that a lot of developers see themselves and the job differently, and the organization also sees the Tech/Engineering team differently. Software has at most 100 years of history, and currently it's still very much the wild west and every team is trying to stumble upon a process that is sustainable. The difference is that building physical buildings has happened for thousands of years and there is a lot of history to compare with the current day. 30% of costs wasted seems like the better end for software. I'm afraid that a lot of churn in Software Development also comes from a similar overspecialisation, overplanning, and the wrong kind of feedback loops. It's a bit weird that now we're taking missed plans as the default, when the Empire State Building (and NYC skyscrapers of the time) ran ahead of their schedule, with Lean principles by focusing on constraints and workflow instead of planning the minute details. I'm not sure whether the architect in your case _can_ come back to the site and direct the constructors against the drawings, even if the later directions are more suitable to build. This is why the continuous feedback is important. As with Software Engineering/Development, there are questions that only surfaces when we do a part of the building, and can't be predicted. CA ended up declining to work with the client due to that. The client wants the engineer to start and finish his survey first and then for CA to receive the reports only. CA once described a story where he needs a constant feedback with the soil engineer for the start of the project but his request is denied by the client. The architect don't (or can't) verify whether their designs work along the way.

I think it's the overspecialisation of roles and the 'waterfall' aspect of the engineering that normalises this. I recommend reading The Nature of Order for the fundamentals of his ideas and how it fits with the world. I think a lot of his ideas can be applied to software too and even really matches up with Extreme Programming. He has authored books related to identifying architecture patterns with 'liveness' in them, from the very small to the big scale. He even explicitly have drawings rendered 'for regulation' but changes it after it's built.Ĭontext: I'm assuming Alexander here refers to Christopher Alexander. He see what's the terrain like, what's the use like, builds a bit, and reevaluates along the way. I think Alexander's ideas and patterns are very lean processes instead. > Talking to the constructors it is normal for architects to specify the impossible, leaving it to the constructor to actually make it up on the job.īoth Risinger and Baczek subscribe to trying to achieve the 'perfect wall' on the outside: He regularly features Steve Baczek for example, on both his main channel and the 'secondary' Build Show Network, and latter does get into the details of the building process: I watch the YouTube channel of Matt Risinger, a building science focused contractor in Austin, Texas, and he seems talk with architects a lot (and they supposedly make up a good portion of his viewing audience). Sometimes plans are just thrown over the wall, but other times there is more collaboration. It would also depend on the architect, primary contractor, and what kind of relationship they have. The drawings are more for the regulators such as building control than actually for the people working on site.

The down side supertall leaks creaks