Code Simplicity

Preface

Many years ago, I was given a unique opportunity. I started doing volunteer software development for an open-source project called “Bugzilla” that had famously messy code. It had reached what is usually considered the “point of no return” in software development—due to the complexity of the system, it was so hard to modify that all new feature work had slowed to a crawl. Most of the developers were throwing their hands up in the air and walking away from the project in frustration. After all, they were volunteers—they didn’t have to deal with bad code if they didn’t want to.

However, Bugzilla had been around for six years at that point, and it had millions of users. It was one of the backbones of open-source development on the Web—nearly every major open-source project was using it to keep track of the bugs they needed to fix in their software. Some companies—like Mozilla, the makers of Firefox—were using Bugzilla to keep track of every single task that every employee in the company was doing. If Bugzilla died as a project, it would have been a severe blow to the world of open-source development and in a smaller way, to the software industry as a whole.

So obviously, it had to survive. But how could we possibly do that? Normally at this point in the software development lifecycle, organizations tend to re-write their software. But due to developer attrition, we didn’t have the resources to re-write. We barely had the resources to maintain the existing code!

So partially born ...