The Red File Folder

When an analog tool does a better job than a digital one!

This post is a story I’ve told many times, though I’ve never actually written it down. I believe it’s long past time to do that, so here goes!

As crazy as it seems, there are quite a few of us who adopted Extreme Programming (XP) early in the century who worked from a Zero Defects perspective. That is, we believed that, through the XP practices, we could drive the cost of attaining zero escaped defects so low that it wasn’t just a dream, but actually achievable.

Before you start penning your response to the folly of that statement, let me clarify that I’m referring to the application on which we were working, separate from the other “moving parts” such as the programming language, database, operating system and network involved. Essentially, I’m talking about the elements over which we had control. Also, I’m not asserting that any of the systems in question were 100% defect free, but rather that there were no or very few known defects and/or no or very few field-reported defects after release. By very few, I truly mean 3 or fewer.

But that isn’t the primary point of this post. Instead, I’d like to discuss what the Zero Defects approach enabled.

Background

This is the story of how a development team in which I worked from October 2003 to April 2006 operated. I joined the team a few months after they started building this new system. I had actually met with them before they started when they had questions about using XP, so I already knew that was how they were working. I joined as a developer and XP coach, but the coaching aspect really was secondary.

There was a lot to like about the environment when I started. The team was colocated, they had daily interaction with the system’s Customer (Product Owner in Scrum parlance), and there was a good set of unit tests in place. On my first day with the group, I paired with another developer and we completed some work and pushed it to source control and successfully ran all the tests (the original meaning of Continuous Integration)!

The team also had, at the time I started, two manual testers, later expanded to three. The process when I arrived on the team was, when the testers discovered a problem, they took a screenshot, printed it and brought it to the developers to discuss and determine how to fix the issue. During those early days while the system was relatively small, that was sufficient. By early 2004, though, it was becoming less effective and we needed a bit more “process” to handle defects.

Analog is Cool!

The good news was that, in 2004, there weren’t that many defect tracking systems available, especially ones that were free and open source. Bugzilla was proposed, but ultimately we decided to keep it simple with an analog solution: the Red File Folder.

The process was straightforward - when the testers found something, they would, as before, take a screenshot, print and annotate it with the steps taken to expose the problem, come to the developer “pit”, discuss it with anyone who was available and then place the printed sheet in the red folder. If no one was available, the sheet would be just be placed in the folder and the developers would see that something had been added. When a developer was available, they would pull the sheet from the red folder and work on fixing the problem. Quite often the sheet never made it into the folder and a developer would work on it immediately.

When the issue was fixed, often with additional tests in place to verify the fix, the developer would take the sheet and place it in a blue file folder beside the red one. We would often tell the tester that it was done as well.

It’s possible (I don’t remember exactly) that this “signalling system” was influenced by Lean Software Development, which a couple of us were reading at the time. It was simple and effective - a new sheet in the red folder indicated to the developers that there was an issue, while a new sheet in the blue folder indicated to the testers that something had been fixed. There were no intermediate states, there were no “assignments”, there were plenty of face to face discussions and collaboration even to the point of pairing between testers and developers.

There was another effect that this highly visible red folder had - it was a very effective barometer for how the development work was going! If there was a stack of sheets in the red folder, we might be slipping on developer testing and letting issues creep into the system. There were times when we’d stop work on new stories in order to clear out the red folder. Since we were always aware of how many issues were in it, that meant a few hours to a day or so of work rather than deferring new work for an entire two week iteration! We - the developers and testers - didn’t seek permission from anyone else, we just did it.

OK, it was never actually zero!

The net result was that the quality of the system we were building was VERY good! I will say, though, that there were a couple of issues that, as fas as I can recall, were never fixed. One in particular was a strange UI rendering issue that we eventually blamed on something hiding with the Java Swing framework.

The key point, though, was that we dealt with issues almost as soon as we found them.

As a result, our simple system with the Red Folder (and blue folder for completed work) continued to be sufficient and effective for years! No one needed to worry about Jira or FogBugz licenses or Bugzilla updates. The total cost of the approach was literally a few cents, in Canadian currency no less! All we had to do was act as if attaining Zero Defects was a sane, rational approach to building software and use practices that enabled it.

Conclusions

This all happened, of course, long before COVID changed our perspective on physical colocation of the people on a team. The key messages, though, still apply:

1. Fix defects as soon as they’re discovered so that you don’t need to keep track of them!

2. If you can’t fix them all as soon as they’re discovered, use the simplest possible means for tracking.

Perhaps I should create an online tool called “The Red Folder” for exactly this purpose! 😀

Epilogue

I had a second stint on that team from mid-2007 to mid-2008. Both the system and team had grown quite a bit, but the Red Folder was still in use. Sadly, quality had suffered a bit, though it had regressed to what I would call normal levels for software teams not attempting to achieve zero defects. One manager kept pushing for a digital tool for defect tracking, and I was told she finally got her wish a while after I left for the second time in 2008. I was told that after the implementation of the new tool, it took substantially longer for defects to be fixed.