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 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 Bugzilla’s 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 wasn’t just a new method of managing developers, but instead consisted of a series of universal laws—ideas 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.
It’s 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 I’d 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 development—not 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, I’m not saying that what is in this book is perfect. I’m 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, I’d 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 they’re incredibly simple. In fact, when you read some of them, you may think that they are so simple as to be stupid. It’s not that people haven’t known many of these ideas—it’s that they didn’t 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, that’s when you start to realize their true value.
And even if you did know these ideas—maybe every single idea in this book—think 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 didn’t need to have all those bad experiences just to learn the fundamentals of practical software engineering? Well, I hope that is what this book represents—the 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 here’s the first fact I’m going to give you, one of the last ones I discovered:
The difference between a bad programmer and a good programmer is understanding.
That is, bad programmers don’t 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 it’s more important in programming because writing software is almost purely a mental activity where understanding is everything.
Now, I’m not saying that all of the ideas in this book are going to instantly solve your problems for you, or tell you exactly what to do in your specific situation. Instead, this book will give you new ways to think about software development. It’s up to you to use those ways of thinking to solve your own problems based on what’s best for your situation. Only you can actually know enough about what’s going on with your software to make correct specific decisions about it. This book just contains general principles to help guide you in making those decisions.
Even if you aren’t a programmer, you may still find this book useful for several reasons:
It is an excellent educational tool to use in software organizations.
It will allow you to more effectively understand why software engineers want to do certain things, or why software should be developed in a certain way.
It can help you communicate your ideas effectively to software engineers, by helping you understand the fundamental principles on which good software engineers base their decisions.
Ideally, everybody who works in the software industry should be able to read and understand this book, even if they don’t have a lot of programming experience, or even if English is not their native language. Having more technical understanding will help in grasping some of the concepts, but most require no programming experience whatsoever to understand.
You’ll notice, in fact, that even though this book is about software development, it contains almost no program code. How can that be? Well, the idea is that these principles should apply to any software project, in any programming language. You shouldn’t have to know some specific programming language just to understand things that apply to all programming, everywhere. Instead, real-world examples and analogies are used throughout the book to help you get a better understanding of each principle, as it is presented.
Most of all, I hope that this book helps you, helps your software, and helps bring sanity, order, and simplicity into the field of software development.
This book contains a series of definitions, facts, rules, and laws for software development. Most of these are offset as indented, bold paragraphs in the text to highlight their importance.
Definitions tell you what something is and how you would use it.
Facts are just true statements about something. Any true piece of information is a fact.
Rules are statements that give you true advice, cover something specific, and help guide decisions, but do not necessarily help you predict what will happen in the future or figure out other truths. They usually tell you whether or not to take some action.
Laws are facts that will always be true, and that cover a broad area of knowledge. They help you figure out other important truths and allow you to predict what will happen in the future.
Out of all of these, the laws are the most important. In this book, you will know that something is a law because the text will explicitly say so. If you aren’t sure what category some piece of information falls into, Appendix B lists every major piece of information in the book and labels it clearly as a law, a rule, a definition, or just a plain-old fact.
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Used for program listings, as well as within paragraphs to refer to program elements such as variable or function names.
This icon signifies a tip, suggestion, or general note.
This book is here to help you get your job done. If you reference limited parts of it in your work or writings, we appreciate, but do not require, attribution. An attribution usually indicates the title, author, publisher, and ISBN. For example: “Code Simplicity: The Fundamentals of Software by Max Kanat-Alexander (O’Reilly). Copyright 2012 Max Kanat-Alexander, 978-1-4493-1389-0.”
If you feel your use of examples or quotations from this book falls outside fair use or the permission given above, feel free to contact us at email@example.com.
Safari Books Online (http://my.safaribooksonline.com) is an on-demand digital library that delivers expert content in both book and video form from the world’s leading authors in technology and business. Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.
Safari Books Online offers a range of product mixes and pricing programs for organizations, government agencies, and individuals. Subscribers have access to thousands of books, training videos, and prepublication manuscripts in one fully searchable database from publishers like O’Reilly Media, Prentice Hall Professional, Addison-Wesley Professional, Microsoft Press, Sams, Que, Peachpit Press, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, Course Technology, and dozens more. For more information about Safari Books Online, please visit us online.
I have a blog and website at http://www.codesimplicity.com/ where you can see my latest thoughts about software development, make contributions, contact me for speaking engagements, submit comments and corrections, or just send me your thoughts on software development in general.
If you have general comments and questions about this book, you can send them to us at:
O’Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
800-998-9938 (in the United States or Canada)
707-829-0515 (international or local)
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at:
To comment or ask technical questions about this book, send email to:
For more information about our books, courses, conferences, and news, see our website at http://www.oreilly.com.
Find us on Facebook: http://facebook.com/oreilly
Follow us on Twitter: http://twitter.com/oreillymedia
Watch us on YouTube: http://www.youtube.com/oreillymedia
My editors, Andy Oram and Jolie Kanat, have been an invaluable resource. Andy’s feedback was both insightful and brilliant. Jolie’s insistence and support were ultimately what got this book published, and her editing work on the early drafts was appreciated.
My copyeditor, Rachel Head, has a remarkable talent for clarifying and improving everything.
Elissa Shevinsky’s post-publication review changed the tone and flow of this book significantly for the better.
All the programmers that I’ve worked with and talked with in the open source community also deserve thanks—particularly my fellow developers on the Bugzilla Project who helped me try out all the ideas in this book on a real, live software system over the course of many years.
The comments and feedback I’ve received on my blog throughout the years have helped me shape the form and content of this book. Everyone who has participated there deserves thanks, even those who simply encouraged me or let me know they’d read an article.
On a personal level, I am tremendously grateful to Jevon Milan, Cathy Weaver, and everybody who works with them. In a very real sense, they are responsible for my being able to write this book. And finally, my hat’s off to my friend Ron, without whom this book would not have even been possible.