Now that we know what software design is and the purpose of software, the next step is to define the goals of this science of software design.
From the purpose of software, we know that when we write software, we’re trying to help people. So, one of the goals of a science of software design should be:
To allow us to write software that is as helpful as possible.
Secondly, we usually want people to keep on being helped by our software. So our second goal is:
To allow our software to continue to be as helpful as possible.
Now, that’s a great goal, but any software system of any size is extremely complex, so allowing it to continue being helpful is quite a task. Maintaining it over time can be quite a bit of work. Even just creating the system in the first place can be nightmarish if you don’t have some guidelines to follow, or haven’t already had experience doing it. So that leads us to our third goal:
To design systems that can be created and maintained as easily as possible by their programmers, so that they can be–and continue to be–as helpful as possible.
When software is easy to create, a programmer can spend more time focusing on being helpful to the user, and less time focusing on the details of programming. Similarly, the easier it is to maintain a piece of software, the easier it is for a programmer to have that software continue to be helpful.
This third goal is probably the one traditionally thought of as the goal of software design, even if it’s never stated explicitly. However, it’s very important to also have the first and second goal to guide us.
The phrase “as easily as possible” in the third goal is very important. The idea is to make things easy to create and maintain, not to make them difficult or complex. That doesn’t mean that everything will be immediately easy–sometimes it takes time to learn a new technology or design something well. But in the long run, your choices should lead to easier maintenance and creation for your software.
Sometimes the first goal (being helpful) and the third goal (easy maintenance) are a little bit in conflict–sometimes making your software helpful can make it harder to maintain. However, I believe that these two goals have been much more in conflict, historically, than they need to be. It is absolutely possible to create a totally maintainable system that is yet extremely helpful to its users. And in fact, if you don’t make it maintainable, it’s going to be quite difficult to meet our second goal of continuing to be helpful.
All this, of course, leads us quite nicely back into our Primary Law, which is where we’d be going next if this were a book. The only thing I’d add to the Primary Law article is that under most circumstances, there’s a lot more potential help to be done in the future than there is in the present. (If there’s no potential help to be done in the future for your software, then it doesn’t have much of a life expectancy anyway, so we don’t worry too much about that situation.) In other words (and as I’ll be talking about more, later), by focusing on the second goal (continuing to be helpful), it is often possible to achieve the first (being helpful). That doesn’t mean first goal is unimportant–I’m just giving you something to think about.