Chapter 1

What Is Designing About?

The purpose of this book is to look in detail at how the activities involved in designing can be applied to the context of software development. Both are challenging topics in their own right, so the chapters that follow draw upon a host of ideas that come from quite an eclectic variety of sources. This chapter is mainly concerned with explaining something of the essential characteristics of design thinking, and the various ways in which this is employed during software development. However, since it is largely written from the perspective of “what should a software developer need to know about software design?”, we also provide a brief review of the relevant characteristics of software. After all, it is these characteristics that make the task of designing software to be such a unique challenge.

1.1When is design needed?

In our everyday lives we are surrounded by things that have been designed. The chairs we sit upon, the cars we drive, the phones we use to communicate with others, the houses/flats that we live in. These are all examples of artifacts, things that have been created through some form of human activity. All of these have also been created to meet some form of human need and hence can be considered as providing a solution to some form of ‘problem’.

In the (relatively) early days of computing, Herb Simon (1973) recognised that computers could be used to help address two distinct types of problem.

Well-Structured Problems or WSPs. These are distinguished by having a ‘right’ solution, and some clear tests that help demonstrate that this has been found. For example, to find the roots of the quadratic equation x²−5x+6=0, we can either use inspection or the standard formula to determine that their values are x=2 and x=3. Putting either value back into the original expression provides a simple and complete test of correctness for that solution. Applications such as financial modelling and database transactions provide examples of using computers to address WSPs.
Ill-Structured Problems or ISPs. For such problems there will usually be no explicit formulation, and many possible solutions, with these being characterised by being good or bad rather than right or wrong. For ISPs there will be no definitive test to determine the correctness of a result, and so no way of knowing that the ‘best’ available solution has been achieved (usually termed ‘no stopping rule’). Computer applications such as face or voice recognition, that have to cope with incomplete information, can be considered as addressing ISPs.

When we look at problem-solving more broadly, not just through the use of computers, these distinctions are every bit as useful. Many problems encountered in science, particularly in physics and maths, are well-structured problems that can be solved through mathematical analysis. However, the problems addressed by engineers, including software engineers, are nearly always ill-structured problems. The need for a bridge can be met in many ways, and there are many ways of writing even a simple computer program. So addressing an ISP involves employing some form of design process which enables us to formulate a possible solution and then evaluate how well it might meet a particular need.

The CCC system as an ISP

Let's consider a design scenario that might occur when the software design team start to plan how they will develop the software for CCC.

The head designer suggests representing each car as an object, with its current status being stored internally, and a set of methods that allow customers and other users (such as the maintenance team and the accounting software) to access that status.
The next question is how to organise all of these objects. So a member of the team suggests using an array of objects. One consequence is that every car now has to have an index number so that the relevant object can be accessed.
And then there's the question of how to model the status of a car internally (is it available, unavailable or reserved?).

None of these decisions exists in isolation, and each one has implications for the way that the design will evolve.

Figure 1.1 provides a simple schematic illustration of the different ways in which we need to approach the task of ‘solving’ ISPs and WSPs. A really important distinction is the way that postulating a possible solution to one aspect of an ISP may influence our understanding of that aspect as well as interacting with the ideas we may have for solving its other aspects (indicated by the dashed-line backward pointing arrows).

So this is really a book about how we tackle ISPs within the domain of software development. We look a bit more closely at the nature of ISPs in the next chapter, and in the rest of this chapter we briefly consider some of the other factors that are likely to be involved in designing software.

1.2A bit about software

Before engaging with design concepts and ‘design thinking’, we need to give a (brief) mention to the other word that appears in the title of this book, as it forms an important influence upon the sections and chapters that follow.

In the ‘pre-internet’ era (and yes, there was such a time), software came in two main flavours. System software, supplied with the computer, provided an operating environment and applications written by users were executed in the context that this provided. So, for most purposes, anyone setting out to design an application could do so within a fairly well-bounded context that was largely determined by their choice of programming language and the resources provided through the particular operating system. This didn't necessarily mean that the task of design was easier than it is today though, since the designer might well have to design around a lack of resources rather than having to choose between different ones.

From the early 1990s, the internet era began to extend this context. And at the same time, the emergence of new ideas about how to organise and structure software, such as classes, objects and software services required that developers find new ways of creating and organising applications. In particular, when designing an application, it might be necessary to envisage not just how it would interact with other applications on its ‘host’, but also with applications running on remote computers, where these might or might not need to be developed as part of the design task.

And of course, technology has continued to evolve. Rather than being confined to a local computer, the different parts of an application might now be found hosted in the cloud, tablets, phones or even domestic appliances (the ‘Internet of Things’). Systems might well need to be dynamically configured during execution, and the designer may well only be responsible for part of a much more extensive system or application.

And even in the pre-internet era it was recognised that the effort invested in creating software applications meant that an application might have quite a long lifetime in use. It was also realised that an application might need to evolve during that lifetime in various ways, so as to meet new needs or changes in its environment (Bennett & Rajlich 2000). (What is now often termed evolution was then more likely to be described as maintenance, with adaptive maintenance describing those changes made to address changes in an application's environment.) So the need to anticipate future developments has always provided an influence (or constraint) upon a designer's ideas.

In more recent times, the associated concept of technical debt is one that has introduced a rather different perspective upon design thinking (Cunningham 1992, Allman 2012). Technical debt refers to the future consequences that may arise as a consequence of the current decisions that we make about software development. In particular, it has been observed that, unlike other forms of debt, the repayment of technical debt may well need to be undertaken by those other than the ones who incurred it in the first place. The team that develops a software product may well have no responsibility for its later evolution—so any problems stemming from compromises in the design may well eventually need to be addressed by others.

In many ways, the concept of technical debt highlights a key difference between the ‘student experience’ and the environment within which the software developer operates. Once a particular student exercise has been completed (and assessed), it is discarded and the student moves on to new topics. So students rarely have to think about other than the very immediate consequences of any software design decisions they make. As such, their work incurs no ‘debts’. Unfortunately though, when thinking about software design in almost any other context, the opposite is true!

The CCC and technical debt

Let's consider some possible scenarios for how the business of CCC might evolve and some possible effects that these may have upon the design decisions outlined earlier.

If the scheme proves highly successful, CCC may need to expand their fleet of cars. Consequence: the early decision to use an array of objects might prove inconvenient, although this does depend upon how it was implemented.
Some customers may need larger cars (even though this is a ‘city’ club!). Consequence: while this can be addressed by using inheritance to create new subclasses of the ‘car’ class, doing so may create other problems, such as how to meet the need for billing for use according to car size.
CCC may conclude that they need a more elaborate set of status values, for example: “available but outside of the central zone”. Consequence: this may complicate or extend the set of methods for each object, depending on how these were specified.

None of these is insurmountable, but it emphasises the point that design decisions, especially those made at early stages, may have consequences for later.

So we might reasonably ask if our ideas about how to (successfully) design software have been able to keep up with these changes and concepts? And of course, the answer is both ‘yes’ and ‘no’. Concepts such as architecture and patterns have emerged to help us conceptualise our ideas about software design, but equally, because design ideas tend to draw heavily upon experience, our ability to make good use of these concepts always lags behind. Indeed, it might be argued that the emergence of the concept of agile development implicitly reflects this process of ongoing change. Plan-driven design strategies, as favoured in the pre-internet era, essentially assume a stable operating environment for an application, while agile ones allow designers to adapt their ideas to a changing context, which itself may well be changing (and being clarified) as development proceeds. However, despite this, since design ideas usually stem from experience, technology developments are usually well ahead.

This book therefore aims to provide the reader both with conceptual tools for thinking about how a design might be organised, and also with knowledge about some of the strategies that might be used to produce a design. When thinking about software at this level, the Internet of Things (IoT), the cloud, the mobile phone app, the web application, and the more ‘conventional’ application have much in common, although the detailed realisations might be quite different. Hence this is not a book about software design for distributed systems, web applications, or phone apps, it is a book that explains different ways of approaching the task of software design. And with that, let's get on with thinking about design…

1.3What exactly do we mean by ‘design’?

One of the complications of the English language is that a word can have multiple uses, and we may often have to work out which meaning is intended by considering the context in which the word appears. The word design is just such a word, and in this book we are going to be concerned with exploring a range of key concepts and ideas related to each of its meanings. So it is appropriate to begin by examining just what these meanings are.

Firstly, we can speak of ‘a design’, using it as a noun that describes something that forms a plan of how we intend some artifact to be constructed. Indeed, we often speak of a ‘design plan’ in this context, where the purpose of this is to provide a ‘model’ of how some form of ‘product’ should be constructed. This particular meaning is therefore widely associated with the idea of manufacturing something, whether crafted by an individual, or assembled in a factory (mass production)¹. So, we may have a design plan that provides guidance on how to construct a model boat (or a real one, depending on how ambitious we are), or an item of clothing, or a car. The information provided in the plan about how to realise that design might be quite detailed and need to be followed exactly, which is probably a good idea when building a boat or a kit car, or it might be something of a more strategic nature that we are expected to interpret and adapt, which would be more appropriate when making a garment to fit our own figure.

However, rather than a physical artifact the design plan may describe some form of procedure or process that is to be performed in some way. Again, there are many forms this can take—we can regard a musical score as being a plan for a particular form of process, that is to be followed by the player or players. Again, it may be very detailed, or leave scope for improvisation. Other examples of such procedures might be concerned with form-filling, such as applying on-line for a driving licence or a passport, describing the various things we need to do, and possibly in what order. And of course, we can consider a recipe for making a cake as being a plan that describes a process, but also one that a competent cook will be expected to adapt quite freely.

The two forms of plan can also be combined. As an example, the design for a bicycle may describe both the structure of the bike and also specify the way in which it should be assembled in order to ensure that its physical characteristics are not compromised.

An important characteristic of the use of the word ‘design’ in this way is that we usually associate it with some form(s) of description for the plan. And of course, there are many forms of description, which may employ words, pictures, mathematical forms, musical notation, etc. as well as combinations of these. (Few diagrams are very meaningful without some accompanying text, as anyone who has tried to assemble flat-pack furniture will be only too aware.)

The second meaning, which is closely related to the first one, and probably even more important to us here, is when we use the word design as a verb, as in ‘to design’. This is concerned with the process of designing something—with the goal being to produce a plan. The activity of designing something forms the most creative (and usually challenging) aspect of design as a concept, and indeed, much of this book will be concerned with this second meaning, and with the different processes employed for designing software.

While design plans may vary in terms of how exactly they need to be followed, there is usually a degree of formality associated with their structure that is required to make them understandable. In contrast, design processes tend to be much less constrained, and even following a recommended practice invariably requires some interpretation and adaptation. So we can interpret design thinking as meaning thinking about how to design something.

In this book you will find that we are very much concerned with both uses of the word ‘design’. While their roles are distinctive, they are not wholly independent either: the form of design plan we want to create may influence the way that we approach the task of designing. Likewise, the way that we approach the act of designing will influence the sort of plan that we produce. And of course, the activities of design and implementation of software lack the clear distinction that usually occurs in industrial manufacturing, since many detailed design decisions may be left for the programmer to resolve during implementation. However, wherever possible we will treat them separately, not least for the sake of our own sanity!

1.4Three perspectives upon design thinking

The idea of designing is one that pops up in many of the things that we do—not just when developing software—and what is involved will take different forms. Here we briefly look at three quite different perceptions about what the act of designing might involve. They all offer a different perspective upon what design thinking might involve, and they all have a place in this book.

If we see the word ‘design’ used in a newspaper or magazine, then it is quite likely that we will be looking at the fashion pages. (Admittedly, very few newspapers have technology pages.) This highlights the first perspective upon design—which relates to how some form of artifact is styled, whether it be clothing, spectacles, mobile phones or electric bikes. Indeed, this is probably what many people think of as being ‘design’. It is an important one for software too, for example, when we use ideas from Human Computer Interaction (HCI) and Interaction Design to determine the ‘look and feel’ of a software application—and hence seek to ensure its acceptability to users.

A second perspective is associated with what we often think of as planning. Planning spans a wide range of activities and end-products (think of social planning, game plans, etc.). Again, this meaning is also used in software development, where the activities involved in a development project need to be planned so that effort is used effectively, and where testing needs to be planned so that it is as comprehensive as possible. Although this form is less widely used in software development itself, doing so by creating software from ‘components’ (including software services) can involve elements of this form.

Both ‘design as styling’ and ‘design as planning’ (as we will term them) are largely concerned with how we deploy existing and largely familiar resources. And when new elements appear (such as touch-screens) they are likely to stem from external factors, such as technology developments created by others.

The third perspective is rather different, and we can term it as ‘design as adaptation’. This is concerned with how we create new ways of doing things, often making something possible that couldn't have been done before, usually by adapting and modifying ideas we have used before on some other task, and sometimes combining these in new and different ways. Many ideas we examine in this book provide models that are intended to be adapted, such as patterns and architectural style. Often the degree of adaptation is fairly limited—if we have found an approach that works, we are unlikely to want to change it too radically—but there will still be times when our ideas have to be modified quite extensively to meet the needs of a particular problem. Figure 1.2 provides a very simple illustration of this concept. At one extreme, someone designing a new database system might well be able to reuse and adapt the experiences of previously developing a very similar one, and so the designer can largely reuse their design model. At the other extreme, designing a completely new application may involve bringing together a range of previous experiences and well-known design forms and then adapting them to work together to address the need.

Figure 1.2: The spectrum of adaptation involved in designing

All of these three forms embody the concept and characteristics of design thinking that we explore in the rest of this book, albeit in different ways. While for software development design activities are often likely to relate mainly to the third perspective, there are going to be elements of all three perspectives in many of our examples. As such, they are not distinct concepts, but more a matter of having different ways of viewing things.

So, what is it that characterises design thinking? We explore this more fully in the following chapters, but in essence it involves thinking creatively about how a task is to be performed. Implicitly, design (in any domain) is concerned with finding ways to do things. That in turn requires an ability to envisage how something might work before we set about trying to construct it. For ‘design as styling’ that might involve having a vision of how something might appear and/or behave, and then trying to work out how we can bring that effect about. For ‘design as planning’ we may be concerned with how to use available resources to bring about some result. And for ‘design as adaptation’ we are likely to be trying to identify a set of mechanisms that will produce the desired effect. The key requirement is one of thinking ‘out of the box’—envisaging the end effect that is wanted, and then trying to work backwards to see how that might be achieved.

And this isn't an easy thing to do. While in principle, anyone can create new things, those things have to meet a range of expectations: they must achieve fitness for purpose, be efficient (in whatever way that matters), have an ‘appeal’ to users, and many other attributes as well. Somehow, a good designer can draw all these things together while keeping a balance between them—and while we might recognise that they can do so, that doesn't mean that it is an easy task for them, or easy for us to learn to do the same.

So, as we explore design thinking in this book, the aim is to provide a deeper understanding of what makes for good design (largely in a software context, but sometimes more widely too). That doesn't mean that every reader will become a great designer—but at least you can hope to become a competent one. And indeed, most of us will be satisfied to feel confident that we know enough about software design issues to be able to avoid developing software lemons!

Key take-home points about what designing is about

This first chapter has swept across a fairly wide set of issues related to design itself. Here we very briefly recap some key concepts that will be particularly useful when reading the later chapters.

Ill-Structured Problems (ISPs) are characterised by a lack of true/false properties—and are the type of problem that needs to be ‘solved’ through the use of design rather than analysis. (And software development is definitely an example of an ISP.)
Technical debt is a concept that distinguishes software development that is undertaken ‘for real’ from software that is written as a learning exercise and then discarded. Designers need to think about the consequences of their decisions in terms of their effect upon the future evolution of an application.
Design can be used as a noun. Employed in this way, ‘a design’ means a plan for how some goal is to be achieved, whether this be physical (how to construct something) or a process (how to perform something).
Design can be used as a verb. This refers to the act of designing (producing a plan).
There are different perspectives upon design. Design thinking applies to a range of activities that can all be considered as being design in some form. Three major perspectives on design that are all relevant to software development are design as styling, design as planning and design as adaptation (experience and models).
Designing is creative. When undertaking design activities, our objective is to create something that does not already exist, which involves predicting an effect upon the future that will only be realised if the design plan is feasible. To do so, we need to be able to envisage how something will be done, and then work backwards to devise ways of bringing this about.