[goatinaboat]

prefers working code over comprehensive documentation

This is funny because “working code” might just mean that it doesn’t crash. But does it actually do what it’s supposed to do or does it reliably deliver the wrong results? How would you know without documentation?

The software in the Therac didn’t crash, it quite reliably killed people with its “working code”.

[dawidw]

Using that logic, what would be "working car"? When wheels don't fall apart?

So I think "working code/application/program" is when it does what it is supposed to do. Including not crashing.

[deathanatos]

> So I think "working code/application/program" is when it does what it is supposed to do.

And the point of the comment you're replying to is to ask what is "what it is supposed to do". How do you know what the answer to that question is, without documentation or a specification? And if you try to rely on just verbal communication, in a group of people probably larger than about 1, they're going to have different ideas about what the software is supposed to do.

Some of the most challenging problems I've encountered have been looking at code that does something. What it does is clear enough from the code. But why it does it, or should it do that, that is much harder to answer, particularly if the person who wrote it has left the company or it's been >6 months and they just don't remember.

[frobozz]

I can't picture a single scenario in which "doesn't crash" is the sole criterion by which code is evaluated as "working"