[oliao]

I totally agree with you there, but wouldn't it be even better if we limit the amount of new stuff we haven't tried yet to a size small enough to keep it in our heads? This way, we can eliminate the need for specs; discussing ideas though speech.

[SatvikBeri]

Keeping it small is definitely a good idea when it's possible, but whether that can be done depends on what you're creating.

I've found that this works when making small feature changes/additions to a consumer web app, but fails catastrophically with B2B software that has to interact with client systems (especially old ones!) or legal regulations. If you start writing code after talking to the client, you'll find it's about 30% right and often requires major architecture changes. If you iterate through a spec you can spot a lot of problems right away, especially ones that have to do with obscure quirks in the client's systems.

Note that a spec is essentially an outline designed to be read by and solicit feedback from multiple people. A spec only needs to cover the things that everybody involved can read and discuss. A developer-client spec for a product with no UI might just be a few flow charts + a few words of explanation. A Data Scientist-Developer spec should go into algorithms and math. A spec for a UI-based product should primarily consist of wireframes. Etc.