I’m very interested in applying general design principles to software design. I am convinced that software design is just design applied to a specific material: code. Since design as a discipline is thousands of years old (the pyramids were designed) while software as we know it today is only a few decades old, I find it obvious that there’s a lot to learn from it.

Part of my exploration was to understand more about the design principles other designers use. One very common principle is the “white space” or “negative space”.

The importance of white space / negative space

White space is very often used in design. From clean, readable web UIs, to modern furniture, modern phones, buildings and, of course, art. Here are some examples from an excellent article on the topic:

Moreover, negative space is also used in designs of things that we cannot see. When we talk about sound, negative space is silence. One of my all time favourite songs, “Stairway To Heaven”, owes much of its appeal to the breaks that emphasize the sound. Great actors and public speakers know that silence makes their performance stand out; just listen to Morgan Freeman narrating anything (an example linked here) and focus on the moments of silence.

White space / Negative space in code

There’s no question in my mind that negative space should apply to code as well. But how? I struggled with this question for about two years. Last week, after a conversation on the software craftsmanship slack group (see it at the end of the post), it hit me:

Negative space is what we take out to emphasize the rest.

Negative space in code is what we take out of the code to emphasize the rest.

So, what do we take out of code? Obviously, code constructs like:

• Comments
• Classes
• Methods
• Parameters
• Fields
• etc.

Of course, by “taking out” I don’t mean “completely taking out”, just as much as using white space doesn’t mean every web page should be blank. It just means take out anything that doesn’t serve a goal.

The highest principle of design is intent; anything that expresses intent weakly or not at all should be taken out.

Why should we care about taking things out of code?

There’s no secret that software development is a brain-intensive activity. The cognitive load is often too high for the brain to bear, and that’s when development slows down or mistakes happen.

Remembering and juggling with concepts in your head takes a lot of energy. Anything that you can leave out will make the code easier to work with. Your brain will thank you if you don’t have to try and understand something like this:

What’s Next?

Up to you. What will you take out of your code? Or none of this matters to you? Let me know in the comments.

Conversation with Alex Migutsky (mr_mig):

mr_mig: @alexboly The “whitespace” seems to me to be a lack of continuous signal, a period of relaxation in a system. From the neural point of view, it may be a relaxation of attention “to let things sink in”. Can it be a relaxation of “software design flow” in a sense of giving a system time to settle in (pentesting, stress tests, QA, refactoring)?

@mr_mig I thought a bit more about white space. What you are proposing is more like a break in the design process, whereas white space is something left out of the design as result. (see http://www.alexbolboaca.ro/software-craftsmanship/an-attempt-at-clarifying-the-software-design-vocabulary for more details)

@mr_mig but with this in mind, I thought about what we leave out of code. And I think I’m on to something: the equivalent of white space to code is when a class has two methods instead of twenty

@mr_mig we tend to add more methods, but we delete them and leave space for the mind to comprehend the interface

@alexboly so, it’s kinda SRP?

@mr_mig kinda SRP and ISP