Great software developers use The Joel Test

About 20 years ago Joel Spolsky created a thing called “The Joel Test” to determine how great you are at building software. While you shouldn’t use it to tell if your nuclear power plant software is safe ¹ (his words, not mine) it certainly has stood the test of time. I’ve been thinking a lot about how this Test should change for the next 20 years of software development. Maybe that can be another post. Please, send me your ideas!

Dymaptic gets an 11/12!

Let’s see how dymaptic does. I’m answering these from the point of view of our product, infomaptic, but our consulting projects also score an 11/12, although for different reasons. ²

1. Do you use source control? – Yes
2. Can you make a build in one step? – Yes
3. Do you make daily builds? – Yes
4. Do you have a bug database? – Yes
5. Do you fix bugs before writing new code? – Yes
6. Do you have an up-to-date schedule? – Yes
7. Do you have a spec? – Yes
8. Do programmers have quiet working conditions? – Yes
9. Do you use the best tools money can buy? – Yes
10. Do you have testers? – No
11. Do new candidates write code during their interview? – Yes
12. Do you do hallway usability testing? – Yes

Do you use source control? - Yes

Today, the open-source software movement is centered around code sharing websites (or repositories) like GitHub, Bitbucket, and GitLab. I think in most cases you would have to work hard to not use source control. In a previous life, I have seen developers not use source control… I have even been the IT person tasked with trying to extract code from a dead hard drive, so it’s still worth asking!

An addendum to this might be: “do you commit and merge often?” With all this source control and multiple people working on everything, it can be easy to get into merge conflicts. So, we should all be following standards. For us that’s making small feature branches, committing at least once daily, and merging when the feature is done. And maybe most importantly (and hardest for me) trying not to combine multiple features into a single branch.

And hey, storage is so cheap these days compared to 20 years ago, we might as well just save the entire history of every letter that was typed into the source code.

Can you make a build in one step? - Yes

If you’ve never worked on really large software projects, this question might sound totally crazy. For infomaptic, we have three different repos: the main application, the reporting engine, and atelerix. Atelerix and the reporting engine both generate NuGet packages that infomaptic depends on. Making a build of each of these is a single button press in Visual Studio and deploying infomaptic happens automatically via continuous integration when changes are merged to develop and to main (more on that in the next question). Probably we should have continuous integration setup for the engine and atelerix as well.

Do you make daily builds? - Yes

I’m choosing to interpret this one a little, we don’t have daily builds, but thanks to continuous integration we have builds every time someone merges code. We have two branches that we make builds from: develop and main ³. Whenever code is written it is done in a feature branch and merged to develop via a pull request. That means that every time a PR is completed, we have a new build. We then can merge from develop to main whenever we want to make a release. (This structure also gives us the ability to do hot-fixes to main without having to go through develop.)

We do gate the final deployment a bit from main before it goes live using things like deployment slots in Azure, but that’s probably an entire blog article all on its own.

Do you have a bug database? - Yes

Thankfully the good folks at GitHub provide us not only source control but integrated gissue ⁴ tracking. We constantly log bugs that we find and things that could be better and have a series of tags to help us keep it all organized.

Do you fix bugs before writing new code? - Yes

I’m going to take some liberties with this one as well. We do fix most of the known bugs that are showstoppers, but we do write new code with some known bugs, in particular ones that we don’t have a good solution for yet. That said, we do prioritize fixing bugs in the backlog over new functionality. I think that with the way we structure feature branches and continuous integration it’s ok but not ideal to write some new code before fixing bugs. Also, we are still building the app, so even our bugs are features 🙂

This quote from Joel is very true, and I think that when we start offering infomaptic as an enterprise solution that you can download and install on your own servers, we’ll stick much more closely to this rule. It is much harder to fix software that you’ve given to someone else to install on their system. They are not connected to our continuous integration pipeline (although maybe they should be and maybe that’s what automatic updates are supposed to be).

Do you have an up-to-date schedule? - Yes

I have to give all the credit for this one to Mara. I’m not the best at making schedules, but she keeps us running in top form every week with backlogs and burndowns and buttresses (OK, that’s an architectural term, but I mean that she keeps the schedule that holds the whole development team up)

Do you have a spec? - Yes

Almost all of infomaptic is written in both code and spec form. It’s a living document that I constantly update but it does reflect the functionality that we want in the tool.

Do programmers have quiet working conditions? - Yes

In the time before (The pandemic) we had a nice little office in Portland, OR where a few of us worked daily and the rest of us worked remotely. Now, we all work from home or wherever we happen to be at the time, and I think that’s how it will be from now on. I do like having an office and I look forward to when I can do that again but for now, it’s up to each of us to build our own working conditions that work for us.

Do you have the best tools money can buy? - Yes

For a small startup that is bootstrapped, absolutely. Our biggest expense outside of our people is the software and hardware that we purchase for development. I like having nice computers and I don’t want hardware or software to be in anyone’s way, so if we can spend a few dollars to keep us all productive, it’s worth it.

Do you have testers? - No

Well, shoot. I mean we do have testers; they just happen to also be the developers. We are looking at getting some early adopters using the app soon, and we do test each other’s code during a PR, but we don’t have dedicated testers. Yet.

Do new candidates write code during the interview? - Yes

Absolutely. We do this several ways:

1. An algorithm design session using a whiteboard where we work together to design how something works.
2. Writing out logical solutions on the whiteboard to see how the candidate thinks and approaches problems.
3. Writing that traditional FizzBuzz stuff.
4. Writing code that tries to simulate something real. In our last interview, we actually had the candidate use an early version of the infomaptic API.

Let me say though that the interviewers that try to make super high-pressure environments to test people in are doing it wrong. An interview is plenty stressful enough! It should be a collaborative experience so that you can judge what skills the person has, and you can both see if you like working together. If everyone in the interview (both the people asking the questions and the ones answering) didn’t learn something, you did it wrong.

Do you do hallway usability testing? - Yes

I like showing off what we have built. For infomaptic, we are constantly showing each other new things and are just starting to show clients and get their feedback on early versions of the product. I’d like to do more here, maybe not all the way to things like A/B testing, but working with clients on new features to get their feedback is critical to getting things right the first time, and something that we constantly do in our consulting projects.

1. This quote makes me laugh every time I read it.
2. Our consulting projects do have testers; our clients provide them. But sometimes budgets mean that we can’t use the best tools money can buy, just the most prudent, which in most cases is totally fine.
3. We have not renamed our master branch, but it’s in our backlog to change this to main before our public release.
4. That’s not a typo, that’s what I call a GitHub issue. But I didn’t invent it.