An Attempt At Clarifying The “Software Design” Vocabulary

The teaser

“Design” is an overloaded term that causes confusion in software development. It has at least three meanings: design as result (as in “the design of the application is easy to change”), design as process (as in “I designed it using Test driven development”) and design as aesthetics (as in “I love this design”).

A clear vocabulary is the sign of a mature profession. Therefore, as an effort to advance our profession, I propose fixing the confusion using a more precise set of terms. You’ll find a glossary at the end of this blog post.

On the many meanings of “design”

The English word “design” has a very interesting problem. It can either be used as a verb (as in: “I’m designing a chair”) or as a noun (as in “the design of the phone looks great”).

Design as a noun

According to the online etymology dictionary:

design (n.) 1580s, from Middle French desseign “purpose, project, design,” from Italian disegno, from disegnare “to mark out,” from Latin designare “to mark out” (see design (v.)).

The online Oxford dictionary adds more meanings. Design as a noun can be:

1. A plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made: ‘he has just unveiled his design for the new museum’
2. A decorative pattern: ‘pottery with a lovely blue and white design’
3. [mass noun] Purpose or planning that exists behind an action, fact, or object: ‘the appearance of design in the universe’

Design as a verb

The verb is easier, although it’s interesting to notice it has a different etymology than the noun:

design (v.) 1540s, from Latin designare “mark out, devise, choose, designate, appoint,” from de- “out” (see de-) + signare “to mark,” from signum “a mark, sign” (see sign (n.)). Originally in English with the meaning now attached to designate; many modern uses of design are metaphoric extensions. Related: Designed; designing.

The online Oxford dictionary agrees that the verb “design” has only one meaning, and explains it:

Decide upon the look and functioning of (a building, garment, or other object), by making a detailed drawing of it: ‘a number of architectural students were designing a factory’

A simpler explanation

Confusing? I can simplify it for you.

The verb design can be expressed as “design as process” while the noun design can be expressed as “design as result”.

Design is used today with both meanings in many places:

• “industrial design” for design as process, “the design of the phone” for design as result
• “interior design” for design as process, “the decorations from the interior” for design as result
• “building design” for design as process, “the building blueprint” for design as result

The huge confusion in software development

This semantic issue leads to misunderstandings in software development. Examples are very easy to find:

• “software design” can be both the process (as in “involving more people in software design lead to good results”) and the result (as in “the software design is easy to adapt to new requirements”). To make things even more confusing, some people attach to software design the “decoration” meaning, confusing the design as aesthetics with design as a solution to a problem within certain constraints.
• “object oriented design” is a style of software design as result that uses certain constraints and constructs.  However, there are books written about the process of designing object oriented software. So it can mean both.
• “functional programming” is also a style of software design as result that uses other constraints and constructs. To make things even more confusing, it’s typically called functional programming instead of functional design because the second term can mean “any design that works”. Yet programming is a process, so functional programming can mean “designing software using functional style of programming”.
• test driven development (TDD) is a process for designing software. Finally, something that’s clear (if it weren’t starting with the word “test” which confuses people into believing TDD is mainly about testing).
• “design of the architecture”. That’s a tough one. We typically think of design as applying at a low level, and architecture applying at high level. But, the process to get to the architecture is still a design as process. And the result of this process can be called the design of the architecture, as in design as result.

No wonder we can’t communicate in this industry!

A proposed solution

As any good engineer, I have to ask: is there a solution? Let’s give it a try.

Software design as result

What is really the software design as result? In other words, what is the blueprint used to build the applications?

The code is the software design as result

The only build we do in software is when the compiler (or the interpreter) takes the code (our blueprint) and transforms it into executable instructions that the computer can run. Building is automated; obtaining the blueprint is mostly not. ^{1   2}

This solves one of our problems: how about using for software design as result the specific term “code”?

Let’s test the meaning in context.

Object oriented design (as result) = Object oriented code or code written in object-oriented style

Functional programming (as result) = Code written in functional style ³

I call this a pass.

Software Design vs. Software Architecture

I propose we drop any combination between design and architecture, as in “the design of the architecture” or “designing the architecture”. They sound cool, but they’re confusing. Instead, let’s use “architecture” as the result and “to architect” as the process.

Let’s test it:

“Design the architecture of our application” = Architect the application

“The design of the architecture of the application” = The architecture of the application

Again, simpler language, easier to understand. Pass.

Software Design as a process

The best way I have found is to keep the term “software design” for software design as process. Let’s test it in context:

Object oriented design (as process) = design object oriented code, design code object oriented style

Functional programming (as process) = design using functional style, design functional style code ⁴

Test Driven Development = Test Driven Design (as in the process of designing code driven by tests)

Tests pass.

Software Design as aesthetics

This term applies to software design as result, aka code. “Designed code” can have the connotation of “aesthetic code”. I’ve been in conversations where this confusion was used by people opposing design principles, as in “we need it to work, not to be beautiful”. Yet this is almost never the case in daily conversations in the software industry.

If this is the intended meaning, I propose using a more precise adjective: “beautiful code” or “aesthetic code”.

Other meanings of design

The expression “design patterns” puts an interesting problem to the system above:

• it’s not design as result because design patterns are general solutions.
• it’s not design as process because design pattern is a result rather than an action

We cannot call design patterns coding patterns because  design patterns are portable between programming languages.

There is therefore an additional context for design: solutions that can be implemented in more programming languages or that can be expressed in multiple ways in code.

The term “design patterns” should therefore be kept as it is. I haven’t found any other examples that apply in this context.

What’s next?

Using a clear vocabulary is the sign of a mature profession, one that has figured out and clarified its activities and practices. I believe my proposal clears up many communication issues. I’m also convinced it’s not perfect.

If you think like me that this is important, I propose you do one or more of the following:

• Review this glossary and improve it
• Clarify the meaning of the words you use before talking about design with colleagues, your developer community or when speaking at a conference
• Create an easier format for understanding the glossary. I’m not good at graphical design, but we could use a nice graphical representation of this
• Discuss this in your communities
• Spread it on social media

Glossary

Code = The result of software design

Usage Examples:

• “Object oriented code”
• “The code is easy to change”
• “Functional style code”

Remark:

• Try to avoid “This code is well-designed” because it can be misinterpreted. Try instead to be specific about the qualities of the code: readable, changeable, clean, has good performance, beautiful (see the “beautiful” meaning below) etc.

Software Design = The process of obtaining code that has certain desirable characteristics

Example:

• “I designed the algorithm using Test Driven Development”

Architecting = The process of obtaining and maintaining the architecture of an application

Examples:

• “I architected this application with the help of my team”

Disallow:

• “I designed the architecture of this application with the help of my team”

The (software) architecture = The high level design of the application, concerning mainly strategic decisions

Example:

•   “The architecture allows scalability”

Disallow:

• “The design of the architecture allows scalability”

Beautiful code / Aesthetic code = Code or code structure that has a pleasing effect on the senses of those who read it

Example:

• “This code is beautiful”
• “This code is ugly”

Design patterns = Reusable solutions to problems in specific contexts

Example:

• “We used the strategy design pattern to avoid conditional statements in our code”

Thanks Samir Talwar, Johann Martinsson, Thomas Sundberg for reviewing and helping me clarify ideas in this blog post.

1. The closest thing to this we have in the “real world” is 3D printing: the printing (building) is automated, while someone has to create the blueprint.
2. Incidentally, this also explains why the comparison between software development and construction breaks down easily. We can learn from the experience of building architects and interior designers, but we have little to learn from the building process itself. Plus, blueprints are cheaper to change than brick-and-mortar objects.
3. Unfortunately the natural term “functional code” most commonly means “code that works”
4. Again, unfortunately the natural term “functional design” most commonly means “design that works”