You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like

* Supports FooBaz

Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.

Users are dumber than you think, and when they pay you a lot it's never on them.

Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.

> Any software has a spec.

Note that the 'spec' you're referring to isn't the same thing as the 'spec' in your pulled quote. The Java spec tells us that the expression

    var >> 40

refers to the value

    var / 256

This is a bug in Java. It's not a bug in the implementation of the spec - that's what the spec says. But it is a bug in the spec.

To identify that bug, you need another spec that can find fault with the official spec. Only the official spec is written down.

Here are some other common and widely-recognized bugs-in-the-spec:

- The conventional sign of the electric charge of protons and electrons has been reversed.

- Mathematical function applications are written before their argument, when they should be written after.