I think having a great, self consistent spec to build from is awesome, but it’s rare that a spec doesn’t require revision after contact with reality; and at that point, it’s just another kind of software.
This is the key - most of our writing on modern software comes from people building things with requirements that are unclear. There are pockets of the software world where detailed specs work wonders.
One of my professors in college had made a career writing these sorts of specs in a certain niche of robotics. It'd worked fabulously for him precisely because nothing was new or innovative, it just required exacting craftsmanship.
If there is no separate record of how the system should behave there is no clear line between bugs and features, and the software will grow warts based on the vagaries of the ticket system. Often at that point someone proposes a rewrite to clean things up (aka “build it twice”), but unless the second time a proper spec is created the end result after a few years is often equally filled with warts. Quality is a process and not a feature, and the same process will usually produce a similar quality. I’ve seen the same software rebuilt four times, and only the fourth time was it preceded by a proper spec resulting from extensive user conversation. That fourth castle stayed up.
I’ve not completed an entire server or browser, so not speaking from implementation experience, just the word on the street.
Is that stale information now?
Listened to the full interview, and definitely rooting for Andreas et al with Ladybird.