Consulting and the Joel Test [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about programming within the scope defined in the help center.

Closed 9 years ago.

Improve this question

The Joel Test sounds like a list of attributes I'd like to work with (and doesn't it for most of us?) But in a consulting context, it can vary a lot. I've been told it开发者_运维百科 depends on the customer, which in some cases do not even have source control (egad!)

Is it justified to turn down a consulting job on the basis of potentially low Joel Test score in some situations?

Also, how could a low Joel Test score be remedied? Is on-the-go version control feasible (say you have it on a laptop you bring on every job)? Would that be accepted everywhere? Ideas? Annecdotes?

(Making this a community wiki from the get go, as it is obviously very subjective)

---

You're free to turn down all the consulting jobs that don't pass the Joel Test.

You're also free to starve.

Pick one.

---

In 30+ years of consulting, almost none of my clients have scored more than 1 or 2 on the Joel Test. A few scored in the high 8's, but those were the exception, not the rule.

"Is it justified to turn down a consulting job on the basis of potentially low Joel Test score in some situations?"

You can turn down anything you want for whatever reason you want. No one cares about the justification.

Seriously. You're opinion doesn't count for anything.

Clients who are desperate for staff will not care why you turned them down. Your rejection will not lead to sudden moral crisis where they rethink their mistakes.

Your opinion of their development practices doesn't matter at all. Your reason for turning them down doesn't matter. You don't need to "justify" anything.

Indeed, they'll usually laugh if you explain why you turned them down. They know that what they are doing is the level best under their circumstances. They absolutely know that they cannot -- for example -- use source code control because they don't have the time or budget or server space or some other ridiculous excuse.

You can point it out all you want. They generally won't care. They can't care, since they know what they're doing is already ideal under their unique circumstances.

"Also, how could a low Joel Test score be remedied?"

It can't be. A culture that performs poorly, will continue to perform poorly until significant changes to the culture and reward structure are made.

One way to effect change is to work and make the case from inside the organization that things could be better. If you're successful, some folks may seek to emulate what you're doing that's successful. Turning them down does not demonstrate successful software development practices.

"Is on-the-go version control feasible?"

Yes.

I have a laptop I bring on every job.

"Would that be accepted everywhere?"

Mostly. A few locations get nervous about consultants bringing in "outside" devices. They also complain that video and sound recording devices are strictly forbidden, yet iPhones are allowed. So, if they want to create trouble for you, they can.

Some places won't let you build code on your laptop. Some will let you.

---

The Joel Test roughly rates the quality of a software team. You can do things as an individual to try to raise a low test score, but that won't change the basic problems endemic to a particular team. If a software team doesn't use source control, you can be damn sure that they are going to be seriously dysfunctional in many other ways.

Many companies that need to hire consultants are not exactly going to score highly on the Joel Test in the first place. That said, as a consultant you might find yourself in a good position to positively influence that team - you could be the person who installs SVN or git somewhere and convinces everyone to use it. Sometimes a bad team just needs someone with new ideas to help improve things.

You have to decide for yourself where you draw the line on the Joel Test. Personally, I would NEVER accept a job at a place without source control unless they were literally dumping truckloads of cash at my front door, and even then I might give it a second thought. It's just not worth the stress.

---

Most jobs I had that filled 8+ of these tests had no need of consultants.

Clients (from my consultant years) either have no need for the 12 (quick contract) are not interested ("I'm paying you to code, so code") or if your lucky will be happy to listen and help you bring such a system up, and you should have a permanent job offering near the end.

The best thing about being a consultant is to be able to choose who you work with. The #1 reason to refuse another contract with a client is the way he previously treated me, and that includes how I can apply good coding practices. Guess who get's blamed when everything is rushed out with no spec, minimal testing and beta and pirated development software. At first it generate more job (support calls), but the client will soon complaint how things are never done with.

---

This is similar to the questions from direct employees about introducing better process (or better agile) in an environment when you don't have buy in from management.

I think its easier to improve things on ones own without buy in from management if the issue is benign neglect ("Source control, what's that?") and not active sabotage ("I will not pay a cent for any time spent on bug tracking, source control, unit tests or build automation!")

Some process improvements can be done ones own. Run an issue tracker and subversion on your own machine and track your own work. Use portable apps like XAMPP to host apache and any php bug tracker if you need to, or an internet accessible bug tracker and source code host if the client isn't specifically prohibiting it. If they don't pass the Joel test, they're clueless enough to not be able to micromanage you, so you should have the flexibility to automate your build, using TeamCity or Luntbuild if the're isn't any money in the contract for tools. Most clients want developers to be in the loudest environment possible, so invest in good headphones-- some headphones can block up to 20 decibels of background noise.

Even Joel (on one of the SO podcasts) has said that specs as a communication tool promise more that they can deliver. If the client is failing on everything except having a spec, then I wouldn't trust their spec to be useful either. You can code to the spec, but that won't make them happy because it takes a sophisticated customer to know what they want in detail when buying custom software. A contractor can always opt to write a spec, it's a just a matter of time and will you be able to bill for it.

The rest of the Joel test items are management issues that individual (be it a contractor or direct hire) initiative can't influence (outside of a non-binding recommendation)-- budget, interviewing process, office layout, who's available for testing, etc.