1. On Design

Introduction to design

Virtually everything made by humans is designed. The discipline of design spans many fields, from landscape and building architecture to industrial product creation to graphic and typographic presentation.

In class, we start by considering posters of and advertisements for some high-end sports cars. By asking the question why repeatedly, we can infer the design goals for these graphics. The designer of a Ferrari poster wants the viewer to experience some measure of awe. We are meant to think that this car must be fast, expensive, and of the highest quality. It is exclusive.

The familiar image of a sports car poster gives way to a rather transparent set of design goals. We can now consider whether those goals were met, though this is not something we are in a position to judge very well. Instead, let’s pause to observe that even an object so mundane was designed with specific goals in mind.

Design is undertaken with specific goals in mind. When we evaluate a design, we rate it based on how well it achieved its goals. In this course, we will evaluate the designs of systems against goals such as reliability, utilization, and scalability.

We also examine in class several examples of apparent design mistakes, including:

• A column in the middle of a walkway
• An ATM machine that is too high on the wall to be easily reached
• Baffling arrays of elevator buttons
• Doors that need instructions to pull or push them

These are highly visible reminders that good design often goes unnoticed, while bad design leaves an impression. Design of a human-computer interface shares this property. A good design may feel “intuitive” to users because they (maybe unconsciously) expected that style of interface. On the other hand, users may revolt against unexpected interface presentation and behavior. This can make it difficult to innovate!

Good design can go unnoticed. When a website is available every time we need it, do we think that the web hosting service must be well designed? Perhaps not, but when a website is down or slow, we suddenly have strong opinions on the subject! We are reacting to a problem with availability, which is an aspect of system reliability.

We also look at how information is conveyed, because that is also designed. Again, the elements of design are easier to see when there are errors, like:

• The “Don’t do drugs” message on a pencil, which after use and sharpening, reads “do drugs”
• The “Quit smoking” advertisement on a bus which becomes “Quit school” when the bus is used to transport students, causing a built-in “school” sign to appear
• A t-shirt that appears to say “Don’t Be Happy, Worry”

One lesson from these errors is that we must remember the context in which designs are deployed. Pencils get shorter through repeated sharpening; buses have signs that mechanically or electronically change; people in English-speaking countries read from left to right and top to bottom.

The contextual elements mentioned above are our first hint that, whatever we design, it will very likely be used within a system. That is, the pencil does not exist in isolation. Its primary use is writing (not expressing pithy paternalism), so we can imagine a pencil in interaction with a student, a piece of paper, and a sharpener.

Two characteristics of a system are: (1) it is dynamic, evolving over time; and (2) it is composed of multiple components. In this course, the systems we examine have another attribute, which is that all of its primary components are autonomous.

Autonomous components take actions without direct human control. A robot is autonomous; a coffee machine is not. A self-driving car is autonomous; an ordinary car is not.

Software can run without direct human control, as when a web server responds to requests. Network hardware and software is similarly automated, and runs independently of the web server as well. A free (unenslaved) human being is autonomous. Put these together with a laptop, OS, and browser, and we have a system that allows a human to access a web page.

Software design

In this course, we look at software systems design as a form of engineering design. The engineering design process should be familiar to you from your study of software engineering, and consists of activities such as:

• Problem definition
• Solution conceptualization (abstract design)
• Requirements gathering
• Concrete design
• Implementation
• Testing, including user acceptance

Of course, these activities are never conducted in strict phases. (The so-called “waterfall process” of software development was largely a straw man, invented to be knocked down.) In reality, the activities listed above are conducted in whatever order is needed, and overlapping as appropriate. Most importantly, software design is iterative, just like other forms of design.

Nonetheless, a productive design process includes all of the above activities. Defining the problem generates the goals (among other output), which influence all of the other work.

I believe that software development education is missing something important: College courses do not spend enough time presenting and critiquing existing designs. We should study good code to improve our coding skills, and good software system designs to develop those skills.

This course provides an introduction to software systems from a design perspective, using historical systems as case studies of reliability, utilization, scale, and other goals.

To do

• Add example images from my presentation On Design

Further Reading

• To do