About a year ago, a Twitter user tagged me and some other programming authors in a thread where they described the barriers to accessing computer programming books in their country. I’ve been made distantly aware of these problems before—there are many countries in the world where the cost of a book in USD could be a person’s entire weekly salary. I didn’t write any of my books to make money—I wrote them to get a message out and to help people. I usually think that people are more likely to actually read a book if they pay for it, and the point was to get people to read the book, because that ..read more

There are often discussions at software companies about whether they should or shouldn’t have a “monorepo,” meaning “a single, version-controlled repository for all code at the company.” Very often, people base this decision on the fact that this is how Google stores its code. I have now worked in developer productivity organizations at a company with a very advanced monorepo (Google) and a company with a very advanced multi-repo system (LinkedIn), and I have to tell you: most of the valuable properties that people associate with a monorepo have nothing to do with how many source control repos ..read more

When I talk to developers about code complexity, they often say that they want to write simple code, but deadline pressure or underlying issues mean that they just don’t have the time or knowledge necessary to both complete the task and refine it to simplicity. Well, it’s certainly true that putting time pressure on developers tends to lead to them writing complex code. However, deadlines don’t have to lead to complexity. Instead of saying “This deadline prevents me from writing simple code,” one could equally say, “I am not a fast-enough programmer to make this simple.” That is, the faster yo ..read more

When solving a problem in a codebase, you’re not done when the symptoms stop. You’re done when the problem has disappeared and will never come back. It’s very easy to stop solving a problem when it no longer has any visible symptoms. You’ve fixed the bug, nobody is complaining, and there seem to be other pressing issues. So why continue to do work on it? It’s fine for now, right? No. Remember that what we care about the most in software is the future. The way that software companies get into unmanageable situations with their codebases is not really handling problems until they are done. This ..read more

Much like we gain knowledge about the behavior of the physical universe via the scientific method, we gain knowledge about the behavior of our software via a system of assertion, observation, and experimentation called “testing.” There are many things one could desire to know about a software system. It seems that most often we want to know if it actually behaves like we intended it to behave. That is, we wrote some code with a particular intention in mind, does it actually do that when we run it? In a sense, testing software is the reverse of the traditional scientific method, where you test ..read more

In the world of software, it is the job of software developers to solve the problems of users. Users present a problem, and the developers solve it. Whenever these roles are reversed, trouble ensues. If you ever want to see a bloated, useless, complex piece of software, find one where the developers implemented every solution that any user ever suggested. It’s true that the users are the people who know what the problem is, and that sometimes, they have novel ideals for solutions. But the people making the final decision on how a problem is to be solved should always be the developers of the s ..read more

One thing we know about software design is that the future is important. However, we also know that the future is very hard to predict. I think that I have come up with a way to explain exactly how hard it is to predict the future of software. The most basic version of this theory is: The accuracy of future predictions decreases relative to the complexity of the system and the distance into the future you are trying to predict. As your system becomes more and more complex, you can predict smaller and smaller pieces of the future with any accuracy. As it becomes simpler, you can predict furth ..read more

In June, I released a second revision of Code Simplicity. Some of you probably already know, but I thought that I should let everybody else know, too. The most important change is that book gets into the laws and rules of software design much more quickly now. It starts with a completely re-written Preface that tells the story of how I developed the principles in Code Simplicity, and why you might be interested in them. Then it gets into a much shorter Chapter 1 that distills everything from the old Chapter 1 into a few short pages, skips the old Chapter 2 (which was a long discussion about wh ..read more

I don’t often dive deep into the philosophical underpinnings of Code Simplicity, but I’ve been realizing more and more that there are a few philosophical principles behind the writings that would be valuable to share. Also, some of these philosophies haven’t been fully formed until I sat with the work for a long time, applied it in a lot of situations, and talked about it with many people. This one–a theory that I have developed over time about how software can be thought of and worked with in the mind–has sort of been percolating with me for quite a while now. It’s time to get at least least ..read more

What if every software developer could gain the knowledge of long experience without having to go through the pain of repeated failure? What if, instead of being a continuous chaos of complexity and argument, the process of software development could be a sane, orderly progression that was well-understood by every single programmer involved? What if all programmers and their managers shared a common ground for discussing software development decisions–a common ground that was based on facts instead of opinion or authority, and that was actually helpful in deciding what to do on a day-to-day b ..read more