|
Fri
4
Mar '05
|
by Frank Spychalski filed under Work
|
just stumble over a link to the infamous Joel Test. Here are my results:
Do you use source control?
check
Can you make a build in one step?
check, actually build and deploy in one step 
Do you make daily builds?
no, but soon
Do you have a bug database?
check
Do you fix bugs before writing new code?
check, 99% of the time
Do you have an up-to-date schedule?
no, nothing close to a schedule
Do you have a spec?
no, never had and probably never will
Do programmers have quiet working conditions?
no. sometimes, when I’m early at work, but usually not.
Do you use the best tools money can buy?
check, I’m not 100% sure, but at least I get what I need
Do you have testers?
no, only my colleagues
Do new candidates write code during their interview?
no, at least I didn’t
Do you do hallway usability testing?
check, but only because my co-workers have to use my tools
so a lowly 6 out of 12. Pretty bad, but I’ll improve by one soon.
who says if it’s “good” to be able to answer “yes” to a specific question? It depends on the requirements of the project! For my project it would be nonsense to have nightly (yes! you should have nightly, not daily builds!) builds because I don’t work on it every day
and unless someone makes a really big donation I’ll never work with the best tools money can buy, but that doesn’t mean I would write better code if I did (oh, you did want to donate? please do so anyway, I may be wrong!) .
Joel says so
Yes you are right, in our cases it’s probably overkill but it takes very little time to configure and could help to detect some problems. If I could choose between getting nightly builds and e.g. a spec or quiet working conditions I’d choose the later. But nobody gives me this choice…
Some points “pro” regular automated builds:
- the build machine is usually not your own computer and therefore should be independent to the well-known phenomenon “works on my computer”
- there needs to be a certain amount of automation to get regular builds = automation is good because humans keep forgetting details
- if more than one person works on a project, a tool like cruise control kicks the butt of whoever screwed up the repository very fast! The more people on a project the more important this becomes IMHO.
- last: it is soooo easy to set up automated builds everyone should do it!
A good spec/design/schedule is worth a lot but very hard to come by and keep current. If anyone got hints on that one, I’d be glad to hear them
I think the point on “the best tools money can buy” is that a lot of companies know that there are better tools around but for financial reasons, they compromise on the features they get. This is true on version control systems, code quality tools and development environments – especially when the language of choice is not Java, but C++ where no free tools are around and commercial ones are very expensive.
You may as well question yourself why that much companies still use CVS although it is really no longer state of the art and there are a lot of better tools for that purpose.
So a lot of companies prefer to have no tool cause of the money they would have to spend on it. And this is wrong, since you will have a return on investment very soon (The problem might be that this return on investment is hard to mesure).