What do you do when your company is missing somethings in "Joel Test Score"?

Question

I'm really, really impressed with Joel Test score: http://www.joelonsoftware.com/articles/fog0000000043.html. He defined a must-have list that any computer software should follow. It's great if your company scores 12/12, but it's more frequent that your company is missing somethings in that list (actually, my company seems to score 0/12 ...).

What do you do if your company is missing something? I know that some tests are more important than others, and some tests can be fixed by a programmer (not completely). What will you do to reduce missing's affects and improve your working environment, for example, when you have to work in a noisy environment, what would you do to ignore it and concentrate on your work? Please share with us.

Thanks in advance.

Answer 1

If you take a closer look at Joel's blog, you might notice another article, Getting Things Done When You're Only a Grunt, which may help you.

Answer 2

Lesson one in Joel's test should be: Do you regularly critically revisit the software team quality tests?

While I like Joel and the list is a good list, it's only a starting point and without proper knowledge of how to apply any part that that test tells you to apply, you won't get far by just introducing them to your team. Worse, it may do more harm than good.

With a current client, much of that test would've failed when I started out there. Explaining the managers that quality is something measurable in less bugs, better understanding of process and better understanding of delays (!) and cheaper on a very short notice helped me introduce many of those concepts.

It was and always has been hard to introduce any tools that cost money (do the math: a programmer may cost a company $6000 a month all in, that extra tool for $300 a year per seat that saves you 1 hour a day, somehow managers just can't calculate, they'll still consider it too expensive). It's a silly truth and in the end the company will not only loose time, but also the programmers.

But you have to start somewhere. Don't overwhelm the team, but slowly introduce them to new concepts. Source control (a good one, do not, I repeat, DO NOT use Visual Source Safe), feature/debug tracking and quiet working conditions will get you more than halfway, are cheap or free and are easy to introduce. You can (ab)use the feature tracking system for documentation, specifications, bug tracking and planning. Together with rollback facilities of source control this will get you a large part of the x/12 score.

Don't (yet) attempt anything that delays the process or "feels like" a lot of work before any result is seen. These are things like a release schedule, specifications like FD and TD and (very) expensive tools that require knowledge that you currently don't have (interpreting the output from a good memory profiler is an art on itself, for instance). Introduce new concepts slowly and you should be fine.

Answer 3

This is a nice question!!!

I personally have been working on improving our existing software development policies, incorporating new tools and best practices.

The best advice I have for you is this: "Be The Example".

By showing others, like your team members and you leaders how well you do what you do, how well do you manage your code base, your productivity, etc, they will inevitably want to replicate that.

Be patient and remember that doing the right thing is always better, even when others show resistance to change.

Answer 4

The reality is that you may very well not be able to change any of them. And attempting to do so could leave you with little friends, or you in your office banging your head against the wall.

For these, you can take initiative and implement on your own. Maybe it will catch on.

---

• Can you make a build in one step?
  • If you are the build guy, or have access to the build tools, you don't need buy in to get this done.

---

• Do you make daily builds?
  • Same as above.

---

• Do you have a bug database?
  • Well, if you don't install one. You can create a Linux based VM for free and install one of the many open source bug tracking tools. Start using it. If you get requests and bug notices, enter them yourself, and when people ask what your status is, or what the status is of a certain request, you can send them the URL to the bug tracker. You can use it to show your boss your work, etc.

---

• Do you fix bugs before writing new code?
  • Obviously you can address this yourself. Getting everyoen else to do it is a whole other matter and would require by in from your superiors.

---

I find these the most difficult ones to change:

• Do you have an up-to-date schedule?
• Do you have a spec?
  • You might never be able to get this. Schedules slip, companies want to get coding quicker than planning, etc. Seems more like a company culture issue than anything else. Can you change it? Perhaps, but you need buy-in.

---

• Do programmers have quiet working conditions?
  • This supposes you have the space to give to programmers. At one company i worked for, we all had our own offices/areas. But we hired 5x the people and that didn't work anymore. YMMV.

---

• Do you use the best tools money can buy?
  • Maybe you don't need the non-Open Source tools. Maybe you don't even need them. I think Joel's point here is that you need to have the tools to do your job. If you don't have them, you should write a proposal about the costs and benefits and submit that up the chain.

Answer 5

Regarding the version control point, the newer distributed version control systems, like git and mercurial, don't even need a dedicated server. You just need to install them and you can make a repository in whichever directory you're currently in. There's no need to set up a server like CVS or SVN. This makes it nearly painless to do your own version control if you can just get some software installed.

As @StudiousJoseph noted this is one situation where being the example can be pretty easy. The day you can dig up an old version before a bug was introduced and you save everyone a day of work figuring out what changed with a bisect, I bet you'll get a convert to version control.

Answer 6

If your company forces you into bad working conditions, which is a sign of deep disrespect for a software developer, the only thing you can realistically do is start looking for another company ASAP. Sometimes you'll be able to do it, sometimes you won't at least not fast enough, but it's important to give it your best shot, not to sit and just hope that someone will get spontaneous IQ improvement next week if you know what I mean :-)

A few of Joe's items are not essential for all kinds of dev-ing but working conditions are.

Answer 7

The point of the Joel Test:

If your company isn't open to doing these things that make their workers more happy and productive, they aren't terribly rational. I've heard it said that you can't reason a person out of a position they haven't reasoned themselves into. If they just don't know or haven't heard of the techniques but are open, then you should have few problems.

Answer 8

What do I do? I put my head down and finish my contract as fast as I can. Get out of there and move on. But it's contract work, so that's more the deciding factor than anything.
If I had something more like fulltime employment at this theoretical company, then I'm typically trying to change attitudes by providing a living example of how much better it can be to do things a slightly different way.

What I really wonder is 'what do you do if your company scores perfect on the Joel test?', but come on, like that could ever happen. Well, I've never seen it in my experience anyway. Perhaps the answer to that one is 'Blog about how awesome your company is'. 8 D