Client Screening

[Justin Control]

In my current project I have the great pleasure of working with many young developers.

I've noticed that almost all of them use the Spoelsky Test( The Joel Test: 12 Steps to Better Code - Joel on Software) in screening potential employers/clients.

Do any of the developers here use this criterion?

[RasputinDude]

In my current project I have the great pleasure of working with many young developers.

I've noticed that almost all of them use the Spoelsky Test( The Joel Test: 12 Steps to Better Code - Joel on Software) in screening potential employers/clients.

Do any of the developers here use this criterion?

I'm a big fan of Joel and his approach to working and writing softare, but I don't use his test in screening clients.

[cojak]

In my current project I have the great pleasure of working with many young developers.

I've noticed that almost all of them use the Spoelsky Test( The Joel Test: 12 Steps to Better Code - Joel on Software) in screening potential employers/clients.

Do any of the developers here use this criterion?

Only if you're a permie.

The fewer the points, the more likely it will be that you can invoice.

Contractors make good money on shambolic clients.

[jmo21]

When it comes to the "do YOU have any questions" part, I certainly ask some questions like those that are on the Joel Test.

Some of the questions are automatic no's in most places I've worked however, so I'm resigned to not getting yes answers for those:

eg. I find most (not all!) places struggle with these
Do programmers have quiet working conditions?
Do you use the best tools money can buy?
Do you have testers?
Do you fix bugs before writing new code?
Do you have an up-to-date schedule - HAHA!!

These are the really important ones for me:
Do you use source control? (does anywhere not these days??!)
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?

These also lead to further questions around technology that I like to ask. Unit testing, easy to spin up a new test environment, how good are the PC's. etc.

[Kanye]

It's surely a bit dated nowadays.

• Do you use source control?
• Can you make a build in one step?
• Do you make daily builds?
• Do you have a bug database?
• Do you fix bugs before writing new code?
• Do you have an up-to-date schedule?
• Do you have a spec?
• Do programmers have quiet working conditions?
• Do you use the best tools money can buy?
• Do you have testers?
• Do new candidates write code during their interview?
• Do you do hallway usability testing?

I've worked at some ropey places, but haven't come across any without a bug tracker and source control lately.

Big specs and schedules are also less important in this new fangled agile-lean-continuous-delivery world.

[d000hg]

I've worked at some ropey places, but haven't come across any without a bug tracker and source control lately.

They are still out there, maybe it's less common though.

Big specs and schedules are also less important in this new fangled agile-lean-continuous-delivery world.

Good one.

[Scrag Meister]

Big specs and schedules are also less important in this new fangled agile-lean-continuous-delivery world.

Big specs like these?

[billybiro]

Only if you're a permie.

The fewer the points, the more likely it will be that you can invoice.

Contractors make good money on shambolic clients.

Definitely this.

As a permie, the Joel Test represents an excellent quick test to allow you as a potential employee to determine whether the prospective employer is offering a role within an organisation that knows what it's doing, and therefore isn't going to make your life hell by putting up self-made obstacles to you actually being productive.

As a contractor, the types of companies who will "employ" you are the kind of places that are not really geared to doing "proper" software development anyway (if they were, why would they need contractors?) so you're far less likely to get a good response to the Joel Test questions.

And as Cojak has quite rightly said, the less prepared the client is for "proper" software development, the more you can offer as an experienced, professional contractor and hence the more money you can make!

[billybiro]

It's surely a bit dated nowadays.

I've worked at some ropey places, but haven't come across any without a bug tracker and source control lately.

You'd be surprised at how many places (usually smaller places admittedly) still don't have basic tools like a bug database, or the ability to make a build in one step.

Most places these days have source control, but even then, a lot are still using something like Visual SourceSafe, the world's biggest software misnomer if ever there was one! (See: Visual SourceSafe: Microsoft's Source Destruction System)

Although Joel's list is over 10 years old now, it's still very relevant and very, very few organisations - even today - can genuinely claim to score the full 12 out of 12.

Big specs and schedules are also less important in this new fangled agile-lean-continuous-delivery world.

Usable "specs" is still very high on my list of priorities. The problem with "agile" is that most places don't have a clue what it really means, or worse, they specifically define it to mean "do whatever we feel like today, with no documentation or even basic guidelines as to what we actually want".

These are the same companies that actually require a full-featured e-commerce web application, but think that that can be sufficiently defined and communicated by simply telling you to "build me a website". These organisations are same as the ones in the "painter" story I told very recently

[d000hg]

I'm working on a £multi-million system which has used VSS for nearly 2 decades without problems.