Whenever you engage in some activity, it’s a good idea to have some idea of what the purpose of that activity is. What is the end goal, and why are you doing it? For example, when I sleep, the goal is to be rested. When I talk, the purpose is to communicate and be understood.
Similarly, when we write software, we should have some idea of why we’re doing it, and what the end goal is.
Now, is there some way that you could sum up what the purpose of all software is? If there was such a statement possible, it would give orientation to our whole science of software design, because we’d know what we were going for.
Well, I think I’ve managed to derive a single purpose that would fit all software:
To help people.
For example, Bugzilla exists “to help people track bugs.” Firefox exists “to help people browse the web.” Remember, you could browse the web entirely by reading HTML yourself–but Firefox (or your web browser of choice) sure does help.
Even if you wrote a piece of software to help animals or plants, it would still be “to help people help animals or plants.”
Software is never there “to help inanimate matter.” 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? Well, that is somewhat a subjective thing, and somewhat not. Look it up in the dictionary. 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.
People who cannot conceive of helping another person will write bad software–their software won’t help people. In fact, I might theorize (as a guess based on some personal observations) that your potential ability to write good software is limited only by your ability to conceive of helping another.
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, both of those are a way of “helping” yourself, but that’s a pretty limited scope of help and, I would argue, is likely to lead to lower-quality software than software genuinely designed to help individuals do what they need or want to do.
So anyhow, there you have it. When we are making decisions about software, our guiding principle can be how we can help. It’s possible to help more or less, to help fewer or more people or things. With that as a yardstick, it’s possible to understand our Laws Of Software Design and how we should be making decisions about software.