We’re constantly improving the way we create code by systematically working to make our process smarter and healthier so we can serve our clients better.
To do this, we’re using a list by software engineer and writer Joel Spolsky that provides 12 specific things teams can do to write better code. We check ourselves against the “Joel Test” regularly to take the temperature of how we’re doing with our web development.
When we started this process, we saw that we had three of Joel’s 12 suggestions already in place.
- Our developers had quiet places to work.
- We used a testing protocol.
- We got candidates to write code during their interviews.
These things worked well for us, but we knew we could get even smarter and healthier. So our development team has embraced the Joel Test as a way of going above and beyond for our clients.
We began using reliable source control.
This ensures that all people working on a project are putting code in the same place, which keeps us on the same page. It also provides a safeguard against lost code, which protects timelines and functionality.
We gained the capability to make a build in one step.
By making a build in one step and then committing it to the system, we create visibility into the quality of the software as we build. Each time a new build is committed, the system tests all builds to make sure every piece of code is working and integrated together. This process creates feedback loops that catch errors as they happen and improve overall system performance.
We created development specifications for every project.
DevSpecs (our shorthand) sets our developers up for success from the beginning of a project. They spell out both the features that will be built and the data structures we will use to support each user interface. Former IBM software engineer Fred Brooks explained the importance of this kind of planning decades ago: “Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won’t usually need your code — it’ll be obvious.”
We improved our tools so our developers can work quickly and efficiently.
Joel talks about the importance of using the best tools money can buy. We’ve found this to be true, because good tools save labor for our team.
Here are a few things from the Joel test we’re working on now:
- We are making daily builds. Now that we can make builds in one step, we run builds at least daily, and more often if the source code changes.
- We are fixing bugs before writing new code. We care about fixing bugs even more than we do about keeping to a schedule. We inspect for bugs bi-weekly, and if we find one — or if a bug surfaces — we stop and fix it before we do anything else. It’s the same approach the best assembly lines (such as Honda) have: stop the line, fix the problem, and then start again. We’ve found that by prioritizing bug fixes, we actually protect the overall project schedule. It’s one reason we’ve delivered more than a dozen software projects in a row on time.
- We are doing hallway usability testing. This ensures that, well before launch, we can fix unexpected errors that users could stumble into.
- We are improving our scheduling process. This is a company-wide objective. As our team grows, we have to learn new smart and healthy ways to schedule work to keep projects on track and keep team members engaged but not overwhelmed. The goal is creating a schedule that’s consistently up to date for each team member.
- We are creating a bug database. Each project we build has its own bug tracking database. We’re now investigating ways we can give our clients visibility into their bug databases and ways let them easily submit new issues that arise.
The Joel test isn’t the be-all-end-all of software processes, but we’ve found it to be a smart and healthy approach to improving the way we create code.