4 ms·

Wasn't one of the lessons of The Mythical Man Month that building from a spec produced good software? That was talking about System/360, my recollection is that

Wasn't one of the lessons of The Mythical Man Month that building from a spec produced good software? That was talking about System/360, my recollection is that most of the effort went into creating a very detailed and internally consistent specification/manual for the system. Implementation followed the spec, and the results were long-lasting and solid.

bch 3y ago
It’s also “conventional wisdom” that (especially?) with the web, there’s The Way It Should Work, and then there’s The Way It Actually Works, which is all the quirks, etc. 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?
- olliej 3y ago
  The whole whatwg ES3.1/5 saga was dealing with the specs saying what they wanted the world to be (which they did badly and incompletely, and frequently in direct contradiction with) and what browsers needed to do (the “quirks”). The spec as produced by whatwg and the browser vendors actually matched reality, didn’t have ambiguity (or rather any ambiguity that was missed is considered a spec bug/error) and could actually be used to make a browser.
  - bch 3y ago
    That’s heartening to hear. I appreciate you taking the time to point this out.
- Cyberdog 3y ago
  Mostly stale, yes, thanks in some part to the solidification of the specs that the interview touches on. “Quirks mode” is still a thing to some degree in browser engines, but you’ll get farther than ever adhering to the spec.
  - bch 3y ago
    Good to know. Listened to the full interview, and definitely rooting for Andreas et al with Ladybird.
sp332 3y ago
I thought it was the opposite, with Fred Brooks championing “build one to throw away” until software processes had developed to a more flexible, iterative model. But that’s because usually there is no trustworthy spec, and in this case, they can observe a working web browser in the wild to get requirements nailed down.
- doctor_eval 3y ago
  Right - I’m sure he’s the source of the aphorism, “plan to build it twice - you will anyway”. 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.
- Hermitian909 3y ago
  > But that’s because usually there is no trustworthy spec 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.
ZiiS 3y ago
If you can explain a complex system precisley to humans then it is trivial to explain it to a computer.
Joeri 3y ago
Fundamentally defects are deviations between a user’s expected behavior and actual system behavior. That presumes there is an understanding of what users expect, and while a spec can model that, a spec can also bake rules in stone that break user expectations. So I would argue it is not the spec as such that increases quality, but rather having a documented reference of how the system ought to behave, whether written beforehand like a spec, afterwards as documentation, or during in the form of high quality tests. 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.

bch 3y ago

It’s also “conventional wisdom” that (especially?) with the web, there’s The Way It Should Work, and then there’s The Way It Actually Works, which is all the quirks, etc. 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?

olliej 3y ago
The whole whatwg ES3.1/5 saga was dealing with the specs saying what they wanted the world to be (which they did badly and incompletely, and frequently in direct contradiction with) and what browsers needed to do (the “quirks”). The spec as produced by whatwg and the browser vendors actually matched reality, didn’t have ambiguity (or rather any ambiguity that was missed is considered a spec bug/error) and could actually be used to make a browser.
- bch 3y ago
  That’s heartening to hear. I appreciate you taking the time to point this out.
Cyberdog 3y ago
Mostly stale, yes, thanks in some part to the solidification of the specs that the interview touches on. “Quirks mode” is still a thing to some degree in browser engines, but you’ll get farther than ever adhering to the spec.
- bch 3y ago
  Good to know. Listened to the full interview, and definitely rooting for Andreas et al with Ladybird.

sp332 3y ago

I thought it was the opposite, with Fred Brooks championing “build one to throw away” until software processes had developed to a more flexible, iterative model. But that’s because usually there is no trustworthy spec, and in this case, they can observe a working web browser in the wild to get requirements nailed down.

doctor_eval 3y ago
Right - I’m sure he’s the source of the aphorism, “plan to build it twice - you will anyway”. 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.
Hermitian909 3y ago
> But that’s because usually there is no trustworthy spec 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.

ZiiS 3y ago

If you can explain a complex system precisley to humans then it is trivial to explain it to a computer.

Joeri 3y ago

Fundamentally defects are deviations between a user’s expected behavior and actual system behavior. That presumes there is an understanding of what users expect, and while a spec can model that, a spec can also bake rules in stone that break user expectations. So I would argue it is not the spec as such that increases quality, but rather having a documented reference of how the system ought to behave, whether written beforehand like a spec, afterwards as documentation, or during in the form of high quality tests. 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.