I have, OTOH, never once been on a project where going faster was beneficial in and of itself.
steven hoober

To use your NICU analogy it is almost a certainty that a lot of “creating” is happening relative to the creation of the building in parallel with the user-centered architectural research. Timelines on physical construction skew the perception of this, but it is very unlikely that everyone is just waiting around to get some feedback from employees before any work is done on the plan of the building.

Beyond that, physical construction is a horrid analogy for software and anything related to human health/safety makes it a whole other ball of wax. One of the major advantages of software vs. physical construction is that prototypes are relatively easy. “Getting to code” faster is more analogous to building a sample NICU in the parking lot and letting people test it out in the parking lot during their breaks. A hospital would have to do this entirely different for safety (no real patients). This would be insanely expensive for a building, but would be a good idea. This is something software developers can do really really easy and it is immensely valuable.

Separate the organizational tendency to turn a prototype into version 1, and focus on the value of the prototype. It doesn’t replace research, but are you honestly saying that the ease of building prototypes doesn’t make you question just how much research should be done, in most cases, before anything is built at all?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.