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!
The bummer about The Joel Test is that you really shouldn’t use it to make sure that your nuclear power plant software is safe.Joel Spolsky
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. ²
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.
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.
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.
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.
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 🙂
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.Joel Spolsky
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).
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)
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.
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.
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.
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.
Absolutely. We do this several ways:
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.
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.