How software design fits into the big picture.
Designing is at the heart of almost everything. Name it, you will find yourself back to design!
What is software design?
Before we go further, lets first get to know what “software design” is. We all know “Software” is a program that enables a computer to perform a specific task, as opposed to the physical components of the system (hardware). But how about “design”? Well, You might have read about it in some books but I would like to share Max Kanat-Alexander’s precise definitions. He defines it from two points:
As a “verb” and as a “noun”.
As a verb, it is to make a plan for a creation. Example: The engineer will design a bridge this month and build it next month.
As a noun, it is a plan that has been made for a creation that hasn’t been built yet. Example:
- The engineer came up with a design for a bridge; he will build it next month.
- The plan that an existing creation follows. Example: That bridge over there follows a good design.
Both perspectives apply when we talk about software design.
When we are “designing software” (“design” as a verb), we are planning it out. There are lots of things to plan about software — implementations plans, the structure of the code, what technologies we’re going to use, etc. There are many technical decisions to make. Often, we just make these decisions in our minds, but sometimes we also write down our plans or draw some diagrams. The result is a “software design” (“design” as the first noun definition). This is the plan that we made.
Anything that involves the architecture of your software system or the technical decisions you make while creating the system falls under the category of “software design.”
Who is responsible for software design?
You may be telling yourself that “hey, I am not a software designer”, and you are surrendering power and responsibility to some title(Software designer) in the industry. Here is the good news🤓 or bad news to those who hate responsibility:
Every programmer is a designer.
Every programmer working on a software project is involved in design. The lead developer is in charge of designing the overall architecture of the entire program. The senior programmers are in charge of designing their own large areas. And the junior programmers are in charge of designing their parts of the program, even if they’re as simple as one part of one file. Did you know this? I didn’t:
- There is even a certain amount of design involved in writing a single line of code.
Every single person on a software team is responsible for making sure that their own code is well designed. Nobody who is writing code for a software project can ignore software design, at any level. However, Kanat-Alexander advises us that this does not mean that design is a democracy. We must not design by committee — the result will be an actively bad design. Instead, all developers should have the authority to make good design decisions in their own areas. A designer should always be willing to listen to suggestions and feedback.
Purpose of software
In almost everything, we need to know the big picture so that we focus and don’t lose track. So as we are designing for software, we need to have the purpose of software in our minds. And it turns out that there is, in fact, a single purpose for all software:
- To help people.
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.
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.
What does “help” mean in this case?
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 and 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. It is “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
Here is the fact:
People who cannot conceive of helping another person will write bad software
Overall, when we are making decisions about software, our guiding principle can be how we can help.
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.
The Goals of Software Design
Now that we know the big picture(the purpose of software), the goals of software design are towards that direction.
The first goal is:
- To allow us to write software that is as helpful as possible.
We usually want people to continue being helped by our software. So, our second goal is:
- To allow our software to continue to be as helpful as possible.
The major barrier today to writing and maintaining helpful software is the actual difficulty of design and programming.
When software is hard to create or modify, programmers spend most of their time focusing on making things “just work,” and less time focusing on helping the user.
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.
Most of us are aware of the third goal even if it is never stated explicitly. However, it’s very important to also have the first and second goals to guide us. We want to remember that being helpful now and in the future are the motivations for this third goal.
One thing that’s important to point out about this third goal is the phrase “as easily as possible.” The idea is to make our programs 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 make the creation and maintenance of your software easier.
Lastly, here is another good news 😍:
It is absolutely possible to create a totally maintainable system that is extremely helpful to its users.
I was inspired by Max Kanat-Alexander’s knowledge in his book titled “code simplicity”. I learned a lot of the above from his book.
