Saturday, April 22, 2006

Taking the Joel Test

Recently I had a chance to read Joel Splosky's article 'The Joel Test: 12 Steps to Better Code' After reading through the article I took a few minutes to evaluate a software services company that I am familiar with using the 12 questions that constitute the test. I have reproduced the questions and my answers below.

Do you use source control? - No. Most projects that use source control tools do not use them the proper way. Archiving and taking back-ups is NOT Version Control.

Can you make a build in one step? - No.

Do you make daily builds? - No. Build process starts several days (or hours) before delivery. It starts 'offshore' and continues 'on-site'.

Do you have a bug database? - Not in all projects. In fact only a minority of the projects use any kind of bug tracker.

Do you fix bugs before writing new code? - No!

Do you have an up-to-date schedule? - Not really.

Do you have a spec? - Yes.

Do programmers have quiet working conditions? - No!

Do you use the best tools money can buy? - No. (Tools?! *Buy* tools? Are you crazy?)

Do you have testers? - Yes.

Do new candidates write code during their interview? - No! (Code?! Are you crazy?)

Do you do hallway usability testing? - What's that???? Oh you want an answer? Well, the answer is No.

According to Joel, A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time.

This particular company rated 2. It would rate 3 if I grudgingly treat a partial 'Yes' as a full 'Yes' for Question #4 (Bug Database).

Try this for yourself. Be honest. Look long and hard at the results. If you are employed in the Indian software services industry, you have permission to weep.

2 comments:

Anonymous said...

Hi dude,

Heres a company which has the answers for you.

* Do you use source control?
Every single time. Every single developer does. Even the analysts and IMs/PMs do.

* Can you make a build in one step?
Absolutely. You can do anything you would want to do with the project. Just say it like this ....
>build [whatever_you_want_to_do]

* Do you make daily builds?
Every time someone checks in. Every successful build is ready for shipping to the client.

* Do you have a bug database?
Yup. We track what we do. Everyone is involved in the bug life cycle. Everyone knows whats going on with any bug. The "bugs" can't hide from us. ;-)

* Do you fix bugs before writing new code?
We write tests before writing ANY new code. We write tests to expose a bug before going for the kill. We write tests before going for any new coding venture. You are not allowed to add new features if broken tests have exposed a bug.

* Do you have an up-to-date schedule?
Yup. We have the vision, we have the bigger picture, we have a plan, we have the path and we know how to walk the path. Plans and schedules change. And that is part of the journey, not an obstacle.

* Do you have a spec?
Yup. Just enough to get you started. No 100 page docs per 10 lines of code. Our analysts/customers are our live specs.

* Do programmers have quiet working conditions?
Would you prefer a quite cubicle with only your poor soul with you to help you bail yourself out from your helplessness or do you want your whole team sitting right across the table always ready to help the moment they hear the faintest cry for help. And ofcourse, your pair is always there to share your pains. ;-) And yes, you do get time and space to check ur girlfriends love/hate mails. Catch up with friends on IM or just roam in cyberspace. Ofcourse, after work.

* Do you use the best tools money can buy?
We use the best tools. Money is not an issue. If money can't buy them, we develop the best tools for ourselves and rest of the world.

* Do you have testers?
Yup. Our testers are our last line of defence against those armies of nasty bugs. Our automated tests hold the trenches quite well. Our testers ensure they have enough rations and ammunition (read test data/cases) to keep them fighting fit.

* Do new candidates write code during their interview?
If you can't code, you are at the wrong place buddy. Please go back to school.

* Do you do hallway usability testing?
Everyone on the project is a user himself. Every developer uses code written by others. Every anaylst/tester uses the application, client people check out the latest working system. No prototypes. We seek frank feedback. Absorb it and do better the next time. And the "next time" could be as soon as the next time you touch the code.

I don't care whats the "Joel" score of my company is. Becos I don't agree with all that he says.

Btw, this company is right here in your town. Its not an Indian company but you will definitely feel at home with all the desis in India and our offices all over the world.

Yes. This is the same company that has been going on in your "Thoughts" and believe me it really "Works" for people like you.

Got it !!!

Ravi said...

thoughtworks is way better than most (indian) compnies.

having said that though,

"* Do you have a spec?
Yup. Just enough to get you started. No 100 page docs per 10 lines of code. Our analysts/customers are our live specs. "

is a "cheat". you can't change the meanings of words in the question to get a "yes " answer.

Joel, when he uses the word "spec", means something very different from the "task card + conversations with analyst" approach that TW follows. There is no way you can answer "yes " for teh question.

So the answer to this question is " No. we have something else which we think is better".

Using rhetoric like "customers are live specs" just obscures the issue.


Likewise "* Do programmers have quiet working conditions?" cannot be answered by "open workspaces are soooo much better"

The correct answer is "no. we have open workspaces". Frannkly, these days (imo) TW(I) is so incredibly noisy that it is wonder to me how anyone can work there without a headache. Even XP was originated in teh context of a maximum of 10 or so developers,. When one scales it oa 100 + devs, perhaps the "open spaces principle" should be reexamined.

The debate between "open" workspaces and quiet,private spaces is far from settled.

Personally (repeat personally) I feel that what works better may depend on the kind of work involved.

If you are working on the typical "enterprise" project, "open" spaces probably work better(assuming afairly small number of devs/analysts/whatever).


If you are designing an operating system, "closed + quiet" works better.

Again, for
* Do you do hallway usability testing?

The answer (for Thoughtworks) is no.

"Usability Testing" means something quite different from "every programmer is a user". or even "clients check out the latest working system" "Usabiliity Testing" is a precisely defined activity and it is neither of the above.

So, in a nutshell, TW has a score of 9 of 12 in the "Joel Test". Which is very good.

Now as to whetehr the Joel test has any intrinsic merit, I agree with you that that can be judged by each person attempting the test. But questions should be answered honestly, without fudging. ;-)