Kanat-Alexander - Code Simplicity: the Fundamentals of Software

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 developmentdue 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 volunteersthey didnt have to deal with bad code if they didnt 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 Webnearly every major open-source project was using it to keep track of the bugs they needed to fix in their software. Some companieslike Mozilla, the makers of Firefoxwere 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 didnt have the resources to re-write. We barely had the resources to maintain the existing code!

So partially born out of necessity, but even more so out of an idealism that abhors throwing away an entire system just to re-write an identical one, I took on a crusade to fix up Bugzillas existing code instead of re-writing it. I and a small group of new developers on the project re-architected the existing system piece by piece and shipped slightly improved new versions every few months. We were still writing new features while we did this, but always in a way that made the code better, not messier.

And it worked. Boy did it work. After three years of fixing up the code this way, we were pumping out features at twice the rate we used to with 1/4th the developers the project used to have (before they all gave up on the old messy code). With an all-volunteer part-time team, no budget at all, and no marketing whatsoever, we remained one of the top products in our field against competitors with massive developer staffs and multimillion-dollar revenue streams.

So how did we manage to do this? Well, for many years before I started working on the Bugzilla Project, I had been developing the seeds of a software development philosophy that wasnt just a new method of managing developers, but instead consisted of a series of universal lawsideas that could be applied to every software project, in every language, that would resolve any situation developers might find themselves in. The problem, I figured, was that there were too many opinions in the world of software and not enough facts. If I could just figure out what the most universal and fundamental facts about software development were, then a lot of other problems would be laid to rest.

The Bugzilla Project was my primary test bed for figuring out these facts, and once they were determined, they made an unbelievable difference in the quality of the code and the success of the product.

Its not enough just to test out an idea on one product and call it a fact, though, no matter how successful it may be. So once I had a good idea what these facts were, I started brand-new personal projects to see the difference they would make there, and they worked just as well. Then I started to interview programmers about the situations at their organizations and the history of their software. I wanted to see if I could find counter-examples to these facts, and I found none. Instead, I learned that I could predict the end of nearly every software development story simply by hearing it halfway through, using the facts Id discovered.

All of this is still not enough, of course. I tried out the ideas on several other real-world projects and found them equally true there as they were on Bugzilla. I presented my ideas to thousands of developers to see if anybody could come up with a counter-example from their experience, and nobody ever did. I looked up numerous experiments that had been done with software developmentnot to see the conclusions, which were often erroneous, but simply to see if the data that researchers had tracked backed up these ideas, and it completely did. I studied the history of software development and the trajectories of famous software projects to see if they matched these ideas, and they did. There is, as far as I am aware, no piece of experience or data anywhere in the history of software development that contradicts what I am about to tell you in this book.

Now, of course, Im not saying that what is in this book is perfect. Im just saying that it works. As far as I have been able to, I have proven that each of the ideas contained herein will improve any software project that they are applied to. Now that the ideas are formalized, Id love to do some stronger science on them in better-crafted experiments, but until then I think they are practical enough to deliver to you as they are. I truly believe that they are the universal laws of software development, that they represent actual natural functionings of the universe in which we live, and that they have the potential to help make every software project simpler, saner, and more successful.

The strangest thing about these ideas is that theyre incredibly simple. In fact, when you read some of them, you may think that they are so simple as to be stupid. Its not that people havent known many of these ideasits that they didnt know they were laws . Once you start thinking with these ideas as the fundamental basis for all good software development decisions, as unshakable truths from which all best practices are derived, thats when you start to realize their true value.

And even if you did know these ideasmaybe every single idea in this bookthink about it this way: what if all new programmers could learn all of these ideas without having to go through all the hard experiences you had to have? There are so many new programmers coming into the field right now that some companies are in a continuous confusion of bad practices resulting from inexperience. What if new developers didnt need to have all those bad experiences just to learn the fundamentals of practical software engineering? Well, I hope that is what this book representsthe opportunity for all developers, both highly experienced and brand new, to gain the most important understandings about software that there are to be had. Because heres the first fact Im going to give you, one of the last ones I discovered:

That is, bad programmers dont understand what they are doing, and good programmers do. Believe it or not, it really is that simple. The more you understand what you are doing, the better you can do it. It applies to programming just the same as every other field in the world, except that its more important in programming because writing software is almost purely a mental activity where understanding is everything.