Based on his experiences as chief architect on the Bugzilla Project and his current employment at Google as a software engineer, Max Kanat-Alexander (@mkanat) has formulated a method and philosophy for designing effective code that is, at its core, all about simplicity. He wrote a book about these ideas, “Code Simplicity,” in which he explains how developers can optimize the structural plans for their software projects.
In the following interview, Kanat-Alexander discusses the negative factors that can lead to messy code and why a large number of developers on a project doesn’t have to undermine the quality of software design.
What are the factors that lead to “non-simple” code?
Max Kanat-Alexander: When I look over all the projects that I’ve worked on, everything I’ve read in the field of software development, and all my experiences interviewing developers over the years, most of the non-simple code I see results entirely from human factors. Some people say that the tools are making their lives hard — and they often are — but, ultimately, complexity comes down to whether or not the developer writing the code has a deep understanding of both the specifics of his or her job and the fundamental principles of software development.
It’s those fundamental principles of development that I’m working toward with this book. You know how sometimes a senior developer just knows what they’re supposed to do, but they can’t really explain why to other people? Partially, that’s what brings us so much non-simple code in the world, because we can’t pass down that knowledge effectively to less senior developers. That’s one part of what the book is here to solve: boiling down all of that knowledge and experience into broad, solid truths that anybody can immediately understand just by reading them.
But there’s even stuff that senior developers forget or simply don’t know. When you’re relying entirely on experience to teach people, they’re not all going to have the same experiences. So there’s been no guarantee that a developer will ever get all the basic principles they need to be a truly excellent programmer.
How does the number of developers involved in a software project affect the code’s simplicity?
Max Kanat-Alexander: There’s the famous quote from “The Mythical Man-Month” that adding developers to a late project makes it later. Complexity is the primary reason for that. But a project doesn’t have to be complex just because it has several developers on it.
It’s true that adding new people is going to introduce some complexity, so you should be prepared for that. You’ll want to make sure you have a solid foundation of simplicity in your existing system before you start throwing lots of new people at it, and you can’t throw them at it faster than that foundation will support. Otherwise, the new folks will develop complexity into it.
But there’s no grand rule that says “a project must be complex if it has X developers.” Theoretically, with the right development practices and the right design of your system, you could have a nearly infinite number of people working on one system and still prevent complexity. I think your work might slow down enormously due to all the communication that was going back and forth, but the system could be kept simple if you all really worked at it.
I’m in favor of small teams, myself, but that doesn’t mean it’s impossible to build simple systems with large teams. It’s just much harder than doing it with small teams, and it’s probably going to happen at a much slower pace.
So, to answer your question, having lots of people doesn’t naturally lend itself to complexity, but in the practical world of everyday programming, it sure makes it harder to keep things simple.
What is the wrong way to code?
Max Kanat-Alexander: The wrong way would be to write software without understanding it. The right way would be to write software with as much understanding about it as you can possibly get.
The more you know about what you’re doing, the better you can do it. And that’s what the book is there to give you: the foundations of a science so that you can have the most important understandings there are about software development, and then build on those ideas in your mind and in your day-to-day development work.
What immediate steps can developers take to make their code simple and more efficient?
Max Kanat-Alexander: Let’s talk first about the word “immediate.” Most developers get into trouble with their code because they either don’t plan for the future at all, or they make some sort of bad prediction about the future because they’re impatient and don’t want to wait for the future to arrive so they can actually see it. So, if you want to do something immediately to make your code simpler, it would be to stop thinking so immediately. Start thinking about how much work you’re going to be doing maintaining the system in the future. Maybe it’s worth a little, or even a lot, of work right now so that your system stays easy to maintain. I know that it’s hard to refactor sometimes, and that you really just want to get that feature out there, but it’s worthwhile to be a little more responsible about the state of your code base. You want to make it simpler before you start adding a bunch of new complexity with some great new feature. It’s the “future you” that’s going to benefit from all this, just as much as your teammates. Make "future you" happy.
So, with that in mind, we can tackle the word “efficient.” If we’re talking about being efficient in terms of speed that the program runs at or efficient in terms of space that something takes up, the thing you want to do first is make sure the system is simple and easy to maintain. Because even if you can optimize something now, that doesn’t mean that will be the optimal solution forever. And if you add complexity to the system prematurely just to optimize something, you may not be able to keep the system running optimally over time. So, it’s really simplicity that leads to long-term efficiency, even though sometimes short-term efficiency gains come from adding complexity. I’m not saying you should never optimize — you should, when it matters. But you have to understand the trade-off that you’re making, and you have to think a bit about how the future’s going to mess with your optimizations.
Do you have your own philosophy or set of principles about good software design?
Max Kanat-Alexander: I have this broad set of opinions about software development, and then underlying that, there’s a set of hard facts that I’ve researched and discovered. The book focuses on those facts, with an occasional small bit of my viewpoint thrown in about those facts.
I could write several other books about my personal thoughts on software, and I’m sure there’s a lot more to discover about it, too. But I thought it was more important to develop and deliver a scientific basis for software development first. Once that’s done, we can start to have lots of interesting theoretical discussions about what ideas or opinions might be best.
Code Simplicity — This concise guide helps you understand the fundamentals of good software design through principles you can apply to any programming language or project.This interview was edited and condensed.
Related: