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 20 years ago. 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.
The point is not to make myself feel old, I can do that easily enough on my own. 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 R5?)
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 HCL Domino development, especially what you might call traditional Domino development (i.e. using Domino Designer)? 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.
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 Domino developers. Our tools are written mostly in flavors of C++ and Java, and, other than building Domino 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 traditional Domino development environment.
In fact, our tools have largely been built around the idea of bringing more traditional software engineering disciplines (source control, build automation) to the 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 traditional Domino apps.
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 Domino 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 Domino development, click below. We’re always happy to chat!