4 Comments
User's avatar
Stephan Johansen's avatar

Really nice post!! Which gives good posibilities for reflection :)

One of my main concerns with all of this is: where is the truth in the software we are building? The need for truth is IMHO not binary but exists on some kind of scale from "not important" to "very important". Is it the spec or the code, something in between, or a combination? I guess that the business domain of the software is what dictates this.

No matter how we turn this, it's even more important now than ever before that our teams are working towards the same goal, because if they aren't, the ambiguity of the goal is also amplified!

Richard Sloggett's avatar

Fantastic thought provoking article. Was already doing many aspects of what you describe but am rethinking the overarching approach based on the observations.

Etienne de Bruin's avatar

Thank you Richard.

Neural Foundry's avatar

The Royce framing is devastating - fifty years of an industry building around a methodology its supposed creator warned against. The METR study findings about experienced developers being 19% slower despite perceiving themselves 20% faster might be the most important data point for any CTO right now. The spec-as-prompt paradigm shift you describe essentially elevates architects while commoditizing implementation, which has massive implications for how we structure engineering organizations.