In August 2000, blogger and software entrepreneur Joel Spolsky wrote The Joel Test. It’s a sort of simplified checklist to measure the quality of your software team and, I suppose by association, the quality of the code the team produces.
I’ve been aware of The Joel Test since it first appeared, and I was surprised to learn that the original blog post was written more than 18 years ago. If that doesn’t sound long ago, consider that, aside from the fact that the twin towers of the World Trade Center were still standing, in 2000 George W Bush (narrowly) beat Al Gore in the presidential election. Kevin Spacey won an oscar for American Beauty. Metallica filed a lawsuit against Napster. And Bill Belichick resigned after one day in position as head coach of the New York Jets.
Anyhow, the point is not to make myself feel bad for being so old. The point is that it’s quite surprising to me how The Joel Test stands up after what could be considered a significantly long period of time, especially in software terms. Back then, you’d have been running Windows 2000 (or possibly NT) and IE 5, or possibly Mac OS9 or even IBM OS/2 Warp. And of course if you were running Notes, it would have been R5. (Remember the R5 “I AM” ad?)
So what is the Joel Test, and why should you care? Well, in case you’re not aware, Joel Spolsky is a software developer/entrepreneur who worked for Microsoft in the Excel team in the early 90s and then set up his own software company, Fog Creek Software in 2000, the same time he started his now (relatively) famous blog Joel on Software. He’s probably best known now for being the co-founder and CEO of Stack Overflow.
Back in 2000, Spolsky wrote the post I’m referring to. In it, he addresses the subjects of software quality, or more specifically the quality of a software team, and how you can assure and improve that level of quality without having to put a whole lot of metrics in place and then measure and analyze them over a period of years.
So what is Joel’s magic formula for software team success, and to what extent is it applicable in the world of IBM Lotus Notes and Domino development? There are twelve parts to the Joel Test:
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’m not going to go into the detail of each of these tests here, you can read that on the post itself. But most of these are pretty self-explanatory in any case.
Sidebar: Joel’s approach makes a lot of sense. You may not know this, but back in the mid-2000s, when IBM was busily trying to get its Notes customers to move over to IBM Workplace and start coding in Java, we spent a small fortune (actually a large fortune) developing a software code quality analysis system for Java. We spent a lot of time and effort analyzing the best approach to predicting the bugginess of code based on a large spectrum of different code quality metrics. In the end, we concluded that the best indicator of the number of bugs in a piece of software is the number of lines of code. Sorry if that’s a disappointment.
Here at Teamstudio, we look pretty good against this test. In fact, other than the fact that I think you could probably argue that we don’t technically do hallway usability testing in the way he describes it, we could check off every one of the 12 tests.
Of course, we’re not your typical Notes/Domino developers. Our tools are written mostly in flavors of C and Java, and, other than building Notes templates that support our tools, we only use Domino Designer for testing purposes. So you might look at this list and think that it doesn’t apply in a Notes/Domino RAD-style development environment.
Personally, I’d beg to differ. In fact, our tools have largely been built around the idea of bringing more traditional software engineering disciplines (source control, build automation) to the Notes/Domino platform. Yes, there are many tools available for more mainstream development environments, but there are plenty of reasons why those tools are not well suited to working with Notes & Domino. (We’ll go into those in a future post.)
So have a look through the list, and see how many of them you can check off in your own environment. Not all will necessarily apply to your specific circumstances. But to my mind, it’s a worthwhile exercise, even for Notes developers.
As a starting point, numbers one and two on the Joel Test can be addressed by looking at Teamstudio CIAO! and Teamstudio Build Manager, respectively. Of course, if you start to implement Teamstudio tools in your environment, that’ll go some way toward addressing point 9 also!
To find out more about improving the quality of the software you’re building or maintaining, or any aspects of Notes & Domino development, click below. We’re always happy to chat!