Fog Creek Software
Discussion Board




Your Additions to the Joel Test.

Joel has already mentioned 12 points on his famous " The Joel Test"

http://www.joelonsoftware.com/articles/fog0000000043.html

- what would you add to this?

Personally, I would say -

Does Management Interfere with your work?

Do the management guys have a tech background?

Prakash S
Wednesday, April 23, 2003

Do politics destroy the project?

KenB
Wednesday, April 23, 2003

Do you use your own code (dogfood)?

I know this is not universaly applicable, but where it applies ...

Just me (Sir to you)
Wednesday, April 23, 2003

Do you have a disaster recovery plan?

Phibian
Wednesday, April 23, 2003

Here is what I consider to be an important omission from Joel's test: does the management structure contain anyone who regularly sabatoges other principles of well run software development organizations, and/or who actively uses his resources to combat known best practices whenever possible?  Or, does the company culture itself contain certain malign concepts that run counter to goodness?


The kinds of people or types of culture I am describing tend to radiate from dominant personalities who impose their own personal creed of badness on development efforts. There are many variations of this.


One archetype is as follows: the 'senior' lead engineer who is obsessed with creating new "platform level", highly generic code for any and all needs - but who is too exalted, high and mighty and important to ever "eat his own dog food" by attempting to use his grandly named code in ordinary applications. This person has the power in the organization to make everyone suffer through endless revisions of stuff that is supposed to "one day" reduce all coding to "grunt work". Like sisyphus and the boulder being pushed uphill, the task is never done, "platform" code gets in the way of doing real live applications, common coding needs are always many times harder than they would be without such "generic engines", and real day to day needs suffer.  The pompous lead never listens to the lesser intellects that must work with his stuff, because after all they are losers because they don't get the elegance and innate simplicity of his stuff, which of course must be learned at his feet. (a short description of this is "technology narcissism".)


Another example is the (typically smaller) company that revels in no-process and stupid practices because process will "take the fun away" and "not let us be flexible". Local cargo cults evolve around mistaken notions such as "source control is bad because it gets in the way of us sharing the same source code and merging changes when everyone is done with their sections." The real problem, of course, is that nobody on the team has the professional experience to understand how to separate functionality, and/or is unwilling to refactor code properly, and/or make other changes as needed to permit process to be workable in the environment.


A third example is the company filled with low-achievers who nevertheless have developed a local "personality cult" of the "perfect developer" with total work ethic who can surmount all odds - which in reality means someone young and stupid enough to work like a dog because "no process" leads to continual mistakes and rework.


I realize that it sounds like I am describing a goal in terms of negatives. Not really. What I am doing is listing attributes of an organization that absolutely prevent adoption of important pieces of the Joel Test and the corollary philosophy it entails. You'd have to fire key managers, lead technical people, or even the entire staff in order to impose good process.


And the overwork that the badness creates causes so much activity that anyone's work in such an environment becomes a death march and survival struggle - there is simply no time to implement much less demonstrate best practices.

Nasty Curmudgeon
Wednesday, April 23, 2003

The best of the Joel tests are those which you can answer a plain "yes" or "no" to without qualification:

Do you use source control?  Its a yes or no answer.

Do you do nightly builds?  Also, yes or no.

Are your managers competent?  Reasonable people might disagree.

Here, I'll add one:  You code base has a known stability problem.  You are a month past the business plan ship date. 
a. Do you ship it?
b. If you ship it, do you inform your clients of the problem?

Nat Ersoz
Wednesday, April 23, 2003

Do your developers waste all their time posting to Joel on Software?

Stephen Jones
Wednesday, April 23, 2003

Answer: yes.

Nat Ersoz
Wednesday, April 23, 2003

>One archetype is as follows: the 'senior' lead engineer who is >obsessed with creating new "platform level"

Think we may have worked together ;)

At one place, his nickname was 'god'. What he said, everyone bent over and did. The main project based on his 'technology' was canned after a year or so work by probably 10+ team ... waste of my life.

I stayed 9 months.

Pete Robinson
Wednesday, April 23, 2003

13) Do not oogle the women in accounting.

Guy Incognito
Wednesday, April 23, 2003

Do you have a pool table?

Eric W. Sink
Wednesday, April 23, 2003

Are developers allowed to talk to customers directly?

Andrew Reid
Wednesday, April 23, 2003

Do you even HAVE customers?

Alyosha`
Thursday, April 24, 2003

This one is difficult to know until after the fact, but "does management have realistic attitudes towards deadlines?"  would have to be pretty high upon the list, in my opinion.

anon
Thursday, April 24, 2003

I would think some minimal amount of documentation should be available.  I'm surprised documentation doesn't appear anywhere in the Joel test.  Otherwise you have to depend on having at least one coder who has been around long enough to know how most  of the system works, or pray that your developers write really easy to understand code (yeah right).

Keith Wright
Thursday, April 24, 2003

Better than whether managers have realistic attitudes toward deadlines.  Are developers allowed to estimate their own tasks?

In otherwords, are deadlines predetermined or do they have a basis in reality based on what the people doing the work believe is possible.

Oren Miller
Friday, April 25, 2003

I'd probably phrase the documentation question as :

"Can your project carry on if you're run over by a bus tomorrow?"

Better than being unemployed...
Friday, April 25, 2003

*  Recent Topics

*  Fog Creek Home