Back in the year 2000, I was in the middle of my university studies and learning about software engineering when I stumbled upon a blog post titled The Joel Test: 12 Steps to Better Code. The article talks about twelve questions that developers should ask about a software company to help make a quick assessment of the quality of the organization's output.

At the time, developers widely shared this blog post in the online software development forums I used to hang out in, and it shaped my worldview around building high-quality software. Twenty-five years later, I still use what I learned from this article to sniff out potential pitfalls I might encounter when working with a new team. You'd be surprised at how many teams fail multiple portions of this test in 2025.

The Joel Test Is Not Only for Developers

While the target audience for the Joel Test is software developers, with topics like being able to build an application in a single step or writing code during interviews, many of its teachings apply directly to software testing and QA. Out of the 12 questions listed in this test, one instantly jumped out to me when I first read it: Do you fix bugs before writing new code?

When I read this article, I was a 19-year-old student with zero professional development experience who had barely begun learning to build small, simple applications in a classroom environment. I had no concept about dealing with bugs in a real-world project or working in a team of other developers and testers. I assumed that developers would take their time to write code that worked as intended, testers would validate it, the team would ship it, and move on to the next thing. I never imagined that most teams would move forward knowing there were bugs in the system.

The Harsh Reality of Real-World Projects

As I entered the workplace a few years later, I quickly realized that my idealized view of software development was a fantasy. The first project I worked on professionally (an internal inventory management system for an electronics recycling plant) was full of bugs thanks to the company hiring super-cheap labor and getting what they paid for. Not only were there constant problems with the app, but the boss often deferred fixing most bugs in order to continue adding new features.

When I inherited this project, the number of defects the application's users ran into seemed endless, and new feature requests came in weekly. Unless one of the bugs was a showstopper, the features had priority over everything else. I did what I was told for a while because I didn't know any better. But even as an inexperienced junior developer with little to no on-the-job experience under my belt, I knew that this process wasn't sustainable in the long term. The project was heading down a path of no return, and I needed to course-correct sooner rather than later.

Any attempts to talk with the head of the company—the person making all those oh-so-important feature requests—about slowing down project work for bug squashing to the head of the company would get shot down instantly. His response was typically along the lines of "We could live with these bugs, but we really needed those new features yesterday!" (spoiler alert: we didn't need those features at all, but I can write a whole book about the times this happened to me).

I couldn't articulate why we needed to take a step back and fix the existing broken code, so the same pace of development continued for weeks. Eventually, new development work on the application slowed to a crawl as I couldn't keep up with piling code on top of a rapidly-rotting foundation. The existing bugs made it more and more challenging to add anything new to the system. My boss was surprised. Even though I was sure he thought it was a skill issue, I knew what I was dealing with. Still, I couldn't seem to communicate that the bugs were a huge problem with our application.

Putting the Joel Test to Work

When the situation looked at its worst, the Joel Test popped back onto my radar when I spotted it somewhere online. It appeared right when I needed it, as if a higher power noticed how much I struggled with my first job. When I re-read the article, the question that grabbed my attention the first time—Do you fix bugs before writing new code?—finally made perfect sense. Our company failed this question hard, and I saw how much of a problem not patching bugs caused in the attempts to improve the underlying system.

Thanks to the Joel Test coming back into my life, I finally broke through the pervasive mindset of adding new things and eventually got the project in a decent state where it was no longer a pain to build new functionality. It was a gradual process with a few steps built on top of each other, leading to a successful outcome. Here's what I did to improve my situation, which can help improve yours if you're in the same boat.

Highlight potential losses over probable wins

When presenting a new idea, most of us tend to focus on highlighting the benefits we expect to get out of the process. For instance, my initial attempts at explaining to my boss why we should fix the existing bugs in our application mainly talked about how fewer issues in the system meant building features quicker. That argument sounds fine, but all my boss probably heard was that spending time on bug fixing meant I wouldn't add the new functionality that he wanted soon.

One early afternoon during lunch with a co-worker, where I spent half the time complaining about how I was getting nowhere with my efforts, he told me "Why don't you tell him how much money he's wasting by having you spend less time on developing new features? You'll hit it where it hurts most for his business." My co-worker had recently read about this bias called loss aversion, and it's precisely the type of argument I should have made from the start.

Humans tend to care much more about losing rather than gaining something. Tell someone you'll give them $100, and they'll be overjoyed, but tell them you'll give them $200 with the condition that they have to pay $100 in fees, and they'll be upset even though they ended up with the same amount of cash. With this knowledge at hand, I changed my argument to point out how much money my boss would lose if we kept this pace by calculating how much additional salary he'd pay me with slower development work done. Once my boss understood the concept showing the potential of losing cold, hard cash, he quickly warmed up to fixing bugs quicker.

Keep track of changes over time and showcase them often

The Joel Test includes one item about keeping track of bugs, titled Do you have a bug database? We never did, so I spent a couple of hours asking around and documenting every defect we could find to show it to my boss. Before presenting this information, I decided to play a little guessing game and asked him *"How many known bugs do you think I found in the application in its current state?" *. His response was "I think about five, at most." He was more than just slightly off target—I had found 24 bugs, and that was just in an afternoon.

My boss was initially adamant about spending time fixing defects before building features because he had no clue how many issues I was dealing with while piling on new work. The original development team never bothered to keep a running list of known issues, and despite my co-workers reporting them to the boss when it slowed down their work, no one really knew what was happening. Showing how many problems lurked under the surface made it real for my boss.

Besides showing the harsh reality of the current state of the codebase, I also made a more formal list of new features since it was mainly in a shared, unmaintained document on the company's intranet. I intended to spend all this time writing everything to show the correlation between fewer bugs and faster development, and the best way to do this is by keeping track of these outcomes. Over time, I used this data to show that we reduced bugs and built new features quickly. I also made a point of mentioning these wins as often as possible. Holding tangible data demonstrating the benefits of fewer bugs in the codebase is always better than simply saying so.

Take the time to squash bugs regularly

In a perfect world, developers and testers would have all the time they need to address issues as soon as they arise. Unfortunately, that doesn't work in the real world. Bugs will always show up unannounced, and we'll have to let them slide for different reasons, whether by external forces like deadlines or because we deem them as non-blocking defects that will affect a few users. There's no problem in letting that happen. As you may have experienced, letting issues go unaddressed for too long creates a pileup that seemingly goes from one or two minor bugs that someone can fix in a day to a dozen problems that need a week or more to handle.

Anyone working in a software development or testing team for a while is familiar with the ever-expanding backlog that everyone wants to keep around, yet no one ever does anything with it. To prevent the accumulation of defects from sapping the team's morale, something to consider is to have a recurring "bug bash" where the team's main focus is on fixing bugs in the codebase. I've seen this process work great at startups where the team spends a day or two paying down their technical debt. Some software development methodologies, like Basecamp's Shape Up, even have built-in cool-down periods to provide some space for handling bugs.

In my example, I managed to take one dedicated day a week (Fridays, since it's the day most people mentally checked out for the weekend) to fix bugs, keeping my bug backlog manageable. Admittedly, it might be a hard sell at many organizations, but showing how bugs create some sort of loss and keeping track of what's going on—the previous two points in this article—can help make your case. You can't expect to fix everything during these phases, but the breathing room it delivers to your team will pay off with higher-quality code and faster development with fewer issues down the road.

Wrapping Up

Many software development teams focus too much on new product development without considering what they already have. The Joel Test helped me see the importance of prioritizing bug fixing over feature building, and it yields positive results. I spent a couple of years working on the project mentioned in this article and saw first-hand how we could go from building new functionality at a snail's pace to knocking them out five times faster than before—all because we had less issues to deal with.

The three tips shared in this article around dealing with bugs—showing what you stand to lose if you don't address things, tracking changes over time, and regularly scheduling time to fix problems—aren't the only things that can help your team. For example, you can leverage automated testing and continuous integration to cut down on some of the repetitive parts of the job or establish code reviews so others can help catch issues early. Whatever option you and your team decide to take, know that the initial hurdles needed to prioritize bug fixing are worth the effort in the long run.

If your team is running into issues with too many bugs and needs someone with plenty of hands-on experience to assess your current software development and testing woes, I can help. I've worked with many teams to develop actionable plans that improve the long-term quality of their projects and get them back on the road to success. Book a free consultation with me today, and let's start a conversation.