I want to convince my partners that we should have a spec and that bugs should get fixed before writing new code. Should I refer to the Joel test? Do you think that the Joel test is up to date? I think that not having a spec is bad project management. Do you agree with the Joel test? Could you add something? It doesn't mention for instance Open Source.
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as primarily opinion-based by gnat, MichaelT, Dan Pichelman, Robert Harvey, GlenH7 Aug 9 '13 at 11:26
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.
I think the Joel test is up to date - it's as up to date as much of the other software writing that's "timeless".
Doing product development (which includes software development) without a spec is just madness.
How do you know where you want to go?
There's only one point I'll make about writing a spec (I don't actually think Joel's specs are very good... better than nothing, but not as good as could be). That point is:
When writing a spec, say only what the product must do, not how it is to be done.
This means you don't dictate implementation details in a spec. That's a design activity and you leave that to the experience and creativity of the designers.
[There is only one exception to this rule: Sometimes a particular implementation detail or method is mandated or required, in which case put it in. For example, if the software must be written in PHP and this is not negotiable, then it goes in the spec. There should be very few instances of this.]
I might add: not having bug tracking is an act of equal madness. It's simply the most unprofessional and foolish way to operate and will lead to great pain and suffering.
I'm going to play the devil's advocate here and suggest that the Joel Test is not up to date. It is too general. As technology has matured, the questions should be more specific than when he wrote the test.
Specifications documents, at least big up-front spec documents are not necessary now that we have user stories and Agile development processes. This question should be changed to "Is the level of documentation appropriate to the solutions being engineered?" Smaller, tighter user stories that are delivered upon every two weeks are much more useful in most cases than a big up front document which describes the product in detail. However, if you're building the next Mars Rover, you might want a detailed up front design document. If you asked whether a company has design specs, I would not be surprised to hear a response of "not really, we use agile processes and user stories instead".
Secondly, the "daily builds" question should change to a question about continuous integration. Unless you are building software that takes hours to build (which 99.99% of places will not be doing), the question should ask whether the company uses continuous integration.
Most of the Joel test really hasn't dated at all. It's still a good way of getting an indication of the working environment.