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.
asked Jul 24, 2011 at 2:48
-
2The Joel Test is directed at the software development and developer hiring processes. How is the manner in which you license your software or whether you do or do not publish your source related to that?– Marjan VenemaJul 24, 2011 at 8:38
-
Thanks Marjan for the question. I was thinking that since the Joel test was conceived Open Source has been a trend and if someone if very negative about Open Source then probably I would want to know how a team is opposed to open source, if they are. I agree copyright issues could be beyond the scope but programmer can't work with a team who thinks that open source is a matter of being able to view source and also question 13 could be "Do you have a backup system?" and 14 "Do you have stronger security than MD5?" where answers should be yes.– Niklas RosencrantzJul 24, 2011 at 12:01
-
1Ok, that makes sense. Open source efforts should not only be "consumed", but also contributed to, though not necessarily with code (think monetary support). Backup systems are important, but not confined to development and as such I wouldn't add them to the Joel test. But if I interviewed with a business that didn't do anything about backups, I'd be running for the door. Security I wouldn't add either. For the software developed security it may not be a concern (in-house apps), and so it doesn't lend itself to a yes/no answer, plus security doesn't have to be development specific.– Marjan VenemaJul 24, 2011 at 16:19
-
Thank you for sharing the knowledge with me. It's true that backup is important but not development specific.– Niklas RosencrantzAug 14, 2011 at 19:04
-
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.– gnatAug 6, 2013 at 16:57
Add a comment
|
2 Answers
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.
answered Jul 24, 2011 at 3:07
-
Thanks for the very prompt and valuable answer. Another instance of madness that reached me was the statement that everything should have the same priority. It feels like doing the opposite of these crazy rules will lead to success. Jul 24, 2011 at 4:25
-
4"everything has equal priority" - also know as "everything is #1". This is, frankly, utter bullshit. Everything should be prioritised, brutally, in terms of HARM TO THE BUSINESS. Then you work on the #1. If you are stopped on the #1 for some reason, you work on the #2. And so on. If you have some people who can't work on the #1 for some reason and they end up working on the #9 - thats OK provided there is a good reason. ("I felt like it and its cooooooool" is NOT a good reason). It is also OK to re-prioritise. Doing so more frequently than weekly is also madness. Jul 25, 2011 at 3:47
-
Thanks for the wisdom. I agree completely that everything should be prioritised. My partner also stated that we should not have issues and no issue tracker. But I feel that documenting issues is right and even the market leader keeps an issue tracker. Again, doing the opposite of the rule will work... Jul 26, 2011 at 17:16
-
@909Niklas You probably should look to get another partner, to keep your future life more comfortable...– MarcelAug 7, 2013 at 7:08
-
+1 just for: When writing a spec, say only what the product must do, not how it is to be done.– MarcelAug 7, 2013 at 7:09
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.
