Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

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.

2  
The 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 Venema Jul 24 '11 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 Rtz Jul 24 '11 at 12:01
1  
Ok, 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 Venema Jul 24 '11 at 16:19
    
Thank you for sharing the knowledge with me. It's true that backup is important but not development specific. –  Niklas Rtz Aug 14 '11 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. –  gnat Aug 6 '13 at 16:57

2 Answers 2

up vote 22 down vote accepted

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.

share|improve this answer
    
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. –  Niklas Rtz Jul 24 '11 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. –  quickly_now Jul 25 '11 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... –  Niklas Rtz Jul 26 '11 at 17:16
    
@909Niklas You probably should look to get another partner, to keep your future life more comfortable... –  Marcel Aug 7 '13 at 7:08
    
+1 just for: When writing a spec, say only what the product must do, not how it is to be done. –  Marcel Aug 7 '13 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.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.