[person22]

I work on a product that meets your criteria. We can't fix a class of defects because once we ship, customers will depend upon that behavior and changing is very expensive and takes years to deprecate and age out. So we are stuck with what we ship and need to be very careful about what we release.

[fhd2]

That's why I find any effort to create specifications... cute. In brownfield software, more often than not, the code _is_ the specification.

[suzzer99]

But if you start from the beginning with a code base that is always only generated from a spec, presumably as the tools improve you'd be able to grow to a big industrial-grade app that is 100% based on a spec.

The question is how many giant apps out there have yet to be even started vs. how many brownfield apps out there that will outlive all of us.

[fhd2]

If the spec covers 100% of the code paths, then yes, you're right. But now spec and code are entirely redundant. Changing the spec or changing the code takes the same effort.

If the spec doesn't specify all the details, then there are gaps for the code to fill. For example, code for a UI is highly specific, down to the last pixel. A spec might say "a dialog with two buttons, labelled OK and cancel". That dialog would look different every time the spec is reimplemented.

Unless of course, there was also a spec for the dialog, that we could refer to in the other spec? That's really just code and reuse.

[patates]

This might be the "Steve, Don't Eat It!" version of the xkcd workflow comic.

Whatever you ship, steve will eat, and some steves will develop an addiction.