Before we can dive into the laws of software development, we have to understand what direction we’re heading in with them. What’s the yardstick for determining whether they work or not? Well, ideally we would have some purpose in mind. Then we could say that our ideas are valid to the degree that they accomplish that purpose.
Thus, what we need is a statement of the purpose of software itself. Not the personal purposes of the developers writing it, or the reasons the organization has for hiring programmers, but the actual purpose of software as a whole. Then we can see if our laws and rules help achieve that purpose.
Is it possible to derive a single statement of purpose that would fit all software? Well, I believe that I have.
The purpose of software is to help people.[2]
We can break this down to a more specific purpose for individual pieces of software. For example, a word processor exists to help people write things, and a web browser exists to help people browse the Web.
Some pieces of software exist only to help specific groups of people. For example, there are many pieces of accounting software that exist to help accountants; these target only that specific group of people.
What about software that helps animals or plants? Well, its purpose is really to help people help animals or plants.
The important thing here is that software is never there to help inanimate objects. Software does not exist to help the computer, it always exists to help people. Even when you’re writing libraries, you’re writing to help programmers, who are people. You are never writing to help the computer.
Now, what does “help” mean? In some ways, it’s subjective—that which helps one person may not help another. But the word does have a dictionary definition, so it’s not completely up to each individual what the word itself means. Webster’s New World Dictionary of the American Language defines “help” as:
to make it easier for (a person) to do something; aid; assist. Specifically...to do part of the work of; ease or share the labor of.
There are many things you could help with—organizing a schedule, writing a book, planning a diet, anything. What you help with is up to you, but the purpose is always to help.
The purpose of software is not “to make money” or “to show off how intelligent I am.” Anybody writing with those as their only purposes is violating the purpose of software and is quite likely to get into trouble. Granted, those are ways of “helping” yourself, but that’s a pretty limited scope of help, and designing with only those purposes in mind is likely to lead to lower-quality software than genuinely designing to help people do what they need or want to do.[3]
People who cannot conceive of helping another person will write bad software—that is, their software won’t help people very much. In fact, it might be theorized (as a guess, based on observation of many programmers over time) that your potential ability to write good software is limited only by your ability to conceive of helping another.
Overall, when we are making decisions about software, our guiding principle can be how we can help. (And remember, there are varying degrees of help—one can help a lot or a little, many people or just a few.) You can even prioritize feature requests this way. Which feature will help people the most? That feature should be given the highest priority. There’s more to know about prioritizing features, but “How much does it help our users?” is a good, basic question to ask about any proposed change to your software system.
In general, this purpose—to help people—is the most important thing to keep in mind when designing software, and defining it allows us now to create and understand real laws for software design.
How can we apply the purpose of software to our projects in the real world? Well, let’s say we’re writing a text editor for programmers. The first thing we need to do is determine the purpose of our software. It’s best to keep it simple, so let’s say the purpose is “to help programmers edit text.” It’s fine to be more specific than that, and sometimes it’s helpful, but if the group can’t agree on a specific purpose, at least come up with a simple one like this.
Now that we have the purpose, let’s look at all of our feature requests. For each one we can ask ourselves, “How would this feature help programmers edit text?” If the answer is “It wouldn’t,” we can immediately cross that feature off our list. Then, for each of the remaining features, we can write down the answer as a short sentence. For example, suppose somebody asks us to add keyboard shortcuts for common actions. We could say “This helps programmers edit text because it allows them to interact with the program more quickly without taking a long break from typing.” (You don’t actually have to write these things down, if that doesn’t seem practical for your situation—just having some idea of the answer for yourself is enough.)
There are also several other useful reasons to ask this question:
It helps resolve uncertainties about the feature’s description or how it should be implemented. For example, the answer above about keyboard shortcuts tells us that the implementation must be fast, because that’s the value users get out of it.
It helps the team come to an agreement about the value of a feature. Some people may not like the idea of keyboard shortcuts, but everybody should be able to agree that the answer above explains why they are valuable. In fact, some developers may even have a better idea of how to fulfill that user’s need (interacting with the text editor more quickly) without keyboard shortcuts. That’s fine! If the answer leads us to a better feature idea, we should implement that instead. The answer tells us what’s really needed, not just what the user thought he wanted.
Answering the question will make it obvious that some features are more important than others. This helps the project leaders prioritize work.
At the worst, if our text editor has become bloated with too many features over time, the answer can help us decide which features should be removed.
We could also make a list of bugs, which we could look over and ask the opposite question: “How does this bug hinder programmers’ editing of text?” Sometimes the answer is obvious, so it doesn’t really need to be written down. For example, if the program crashes when you try to save a file, you don’t need to explain why that’s bad.
There are numerous other ways to apply the purpose of software in daily work; these are just a few examples.
[2] This fact (the purpose of all software) is more important than a law. In English, there is no simple word for this type of fact. We could perhaps call it a “senior law,” even though it doesn’t quite fit the criteria for a law (for example, it doesn’t predict the future). For simplicity’s sake, the appendixes at the end of this book list this fact as a law, and otherwise we just refer to it as “the Purpose of Software.”
[3] Note that “to make money” can certainly be one of your personal purposes or a purpose of your organization—there’s nothing wrong with making money. It just shouldn’t be the purpose of your software. In any case, the amount of money you make is likely to be directly related to how much your software helps people. In fact, the two primary factors that determine the income of a software company are probably the business skill of your organization (including administration, management, marketing, and sales) and how much your software helps people.