3 ms·
Always write a spec
- run4yourlives 17y agoIt's this type of thinking though that has lead to some of the most over-engineered pieces of crap ever built. Point being: The person writing the spec isn't the one - 99% of the time - that will be using the software. At the very best - if you are the main user - you're not exactly sure how you will use the software, since it doesn't exist yet; ergo, the spec is always going to be wrong. That's okay if you can keep the spec small and nimble. At that point thought it's just a recording of a thought process. Of course such small iterations are better realized by just writing the code outright, testing for intended functionality and releasing into to wilderness to test whether your assertions about the use of the code are correct. (i.e. testing the spec itself) The faster you can get to that last point, the better you can use your time. In many cases (not all) the act of writing the spec only lengthens the entire process.
- nreece 17y agoSpot on. User Stories (Agile) are a much better tool for managing requirements.
- mahmud 17y agos/spec/unit-tests/g