I‘ve been reading Joel Spolsky’s blog for a really long time.
So long that he’s sort of retired it, or at least changed it substantially from its earlier days.
There are some posts I return to frequently. The Joel Test being one of them.
The Joel Test is a simple 12 checkbox way to tell if your software company is serious about what it does. You may not agree with all of the items on the list, but there’s a darned good reason for each one of them.
Ship it on time is not in the vocabulary
One of the biggest problems software companies have is shipping a product on a schedule. On time, that is.
The biggest ones (Microsoft, Intuit, Apple and Adobe come to mind) seem to have figured most of this out, evidenced by annual releases of their mainstream products (eg: Office, QuickBooks, iTunes and Creative Suite). Naturally, everyone can think of an exception case for those 4 companies.
The rest – especially the smaller ones – seem to get sucked into a maelstrom of delivery problems. Part of the reason is that programming is a bit of an art and a science rolled into one.
Add management issues to that and you begin to see why the Joel Test is so important.
Shipping on time requires far more than just discipline. It requires a system (or systems) for making things happen, or not happen.
Ultimately, this involves people and their performance – which varies widely from task to task.
Shipping on time requires that you know how long things take – and that this varies from task to task and person to person. Not the mythical man-month where we can get 9 pregnant women together to make a baby in a month (a classic software company problem), but the kind where we know that Joe, Sandy and Jerry produce different kinds of work results at different speeds – and that’s OK. Really.
This has applications in your business even if you don’t produce software.
Today’s guest post, Joel’s Evidence-Based Scheduling, discusses how collecting real-world information about how your folks work (and how their work environment works) isn’t just some evil management plan to cut back on the number and lengths of the bathroom breaks employees take, but in fact can be the secret sauce to setting deadlines that make sense to everyone and then going out there and ACTUALLY HITTING THEM.
Yes, all that noise you just heard is software developers and product managers worldwide hitting the floor, or their foreheads, or something.
Think about what it would mean to your business to be able to accurately schedule work and then DELIVER IT on time. Think about what it would mean to be able to do that time after time, despite changes in the work product you’ve been asked to produce (no matter what you do).
Why it’s OK to gather the evidence
Measuring the work you and your staff do serves your business well IF you do it and IF you use what you find to make your company better.
In some lines of work, measuring staff performance is considered evil and predatory and downright wrong. Those folks should be arguing against the poor methods used to measure the work, rather than the measurement itself. No matter what you use, some prognosticate that their work can’t be measured.
Again, please note that Joel’s article doesn’t talk about measuring so he can flog his poor staff, pay them less or belittle them. He simply does it so they can set a date to accomplish a task and have some sort of assurance that they’ll come close to hitting it.
Ultimately, gathering this “evidence” serves everyone – and especially the customer who buys their products. The company that can build complex products and services to spec on time and on budget might just have an edge, ya think?
Saying what you’ll do and then having the systems in place to help make sure you do what you said. How revolutionary.