Agile software development radically changed the nature of software creation. One of the hallmarks of agile is the creation of small increments of end user functionality as opposed to creating software in one or few large portions. Agile also included many other innovations such as starting with confirmatory tests as opposed to creating tests after construction and creating self managed teams as opposed to traditional command and control. There was an earlier, parallel movement in understanding the design and creation of mechanical objects, including building architecture, product design and graphic communication. One of the major contributors to that movement was Bryan Lawson. In Lawson’s book, ‘ How Designers Think ‘[1], he explains the characteristics of design problems, solutions and the process. In this article I have explained Lawson’s ideas on design problems, solutions and the process. Understanding the fundamental nature of problems and solutions can greatly benefit the power of agile increments/user stories.
Context: Iterations, Construction, Teams
- The iterations in agile and the sequential phases of waterfall development can be considered a macro view of the development process. In this article the focus is on the work of an individual developer implementing a user story. The reference to phases in this article is the way an individual developer addresses a user story.
- Agile has made major contributions to organization, culture, collaboration and group dynamics. The ideas presented in this article are not in conflict with the work of a team.
- The design of a building includes the aspects of construction. In software, (user interface) design is a separate and often optional activity. The use of the word ‘design’ in this article includes all aspects of designing and implementing a user story. For this article, let’s assume there is no separate UI/UX designer.
As you read the rest of this article, think of implementing a single user story. This isn’t about using an agile retrospective to create a feedback loop.
Problems vs. Solutions?
Most people think of problems and solutions as distinct. You solve a crossword puzzle or a jigsaw puzzle. A plumber fixes the leaking pipe. You replace the fused light bulb. Software development has a long tradition of solving problems. Software algorithms are mathematical/logical steps to solve problems. Common algorithms include sorting a list of numbers or searching a list for a value. Google search is based on a celebrated algorithm.
Design problems and solutions are different. When you design a library, is the library the problem or the solution? Does the client specify how the library should look like? In that case is he specifying the problem or the solution? In a student problem of designing a library, the student starts by asking about the broader purpose of the project. Even when a client has preconceived ideas about a solution, designers may want to understand the broader goals. A supportive client will participate in the process rather than be fixated on his solution.
In agile software development, there is similar thinking of specifying user stories as a customer need rather than a solution, i.e., what will be built. However, there is often confusion between a traditional specification and a user story.
Solutions improve problem understanding and create new problems
In the past architectural industry associations conceived of architectural design as a set of sequential phases — assimilation, general study, development and communication. However, in reality, often designers cannot gather information until they have studied the problem. Detailed designs often expose problems in the designers understanding of the problem. As a result, the process actually requires designers to loop back to earlier stages. Consequently, a more realistic process would have loops from the later stages to each of the earlier stages. A critical principle is that only when you develop a solution do you realize the flaws in your understanding of the problem. Solutions may also result in new problems. As a consequence, the relative priorities and the objectives of your design may keep evolving throughout the design process (user story).
Problems are subjective
One of the iconic statements about the software development process is, ‘Quality is value to some person’[4]. The understanding is that the value that people derive from software solutions is subjective. However, the interpretation of problems themselves may be subjective. Lawson asserts that industrial designers may focus more on the way ‘buffet cars are laid out’ in a train, while operations researchers may focus on ‘timetabling and scheduling of services’ and graphic designers on ‘how the food is marketed’. In software teams you can observe differences in engineers with expertise in databases as opposed to systems developers, or engineers who work in IT compared to those who develop software products.
Thinking approaches redefine the problem
Lawson (quoting Eberhard [5]) describes a partly humorous account of an architect designing a door knob, questioning whether the door really needs a door knob to open. This results in questioning why they need a door in the first place. Another type of thinking, results in a student designing a library [6], to become immersed in understanding how libraries work in excruciating detail. There are probably many other ways in which you can think about problems which can prolong the problem definition. In software instead of creating a user login you may decide to use the credentials (username and password) from a social media site like Twitter. Alternatively, you may decide that you really need a way to manage the user’s identity rather than just a credential.
Developers should contribute to problems as much as clients
Given the recursive nature of problems and solutions, you shouldn’t expect static definitions of problems with fixed boundaries. Since solutions result in clarifying problems as well as creating new problems, as developers create solutions, it should be expected that they make contributions to problems. Lawson describes the architect Michael Wilford’s view of the client as ‘(not just) the source of the brief but a creative partner in the process.’ Lawson quotes the architect Eva Jiricna going a step further, ‘the worst client is the person who tells you to just get on with it and give me the final product’.
The role of the user has got a lot of attention in agile development. However, sometimes developers mistake this to mean that the user will provide a static problem definition and later validate it.
Solutions always involve compromise
It is common in design, for different needs to compete with each other. Lawson gives an example of motorists who want better acceleration as well as good fuel consumption. In software, providing detailed logs may compete with system performance. There are certain higher level attributes which always compete with others, such as cost, performance and development time. High performance always competes with cost. In software, an attribute which is often overlooked and can be overbearing is security. As a result of these competing needs, it is difficult to create a solution which is optimal. There are infinite solutions if you can think of them. Given the varying needs of stakeholders and their subjective interpretation, it is likely that some will be more satisfied than others.
Design solutions are always holistic
When you consider the various attributes of a design such as performance, usability, security, it is difficult to map them to specific parts of the design which satisfy these attributes. ‘Designs are integrated holistic responses to a number of problems.’ Designs often satisfy multiple attributes at the same time.
Problem solving is a non-linear, endless process
Given the subjectivity of problems and solutions, and the different ways to think about problems, there is no ‘single infallible approach’ to solving problems. You can always think about new ways of thinking about a problem. You can always find new problems with your solution and further improve your solution. This implies that there is no end to the process and that there are infinite possible solutions.
The nature of problem solving and implementation of user stories
- It’s only when you start creating a solution that you may expose flaws in your understanding of problems
- Solutions will often create new problems
- Interpretation of problems is subjective
- Solutions are based on subjective value judgment (‘Quality is value to some person’).
- Developers should actively contribute to problems. This is part of problem solving.
- The design process, starting from understanding the problem, is an active collaboration between developer and client. (This is because solution development exposes flaws in understanding problems and that solutions may create new problems.)
- There are many approaches to thinking about problems. (different from thinking about solutions)
- Solutions always involve compromise.
- Design solutions are holistic.
- There is no single infallible process of implementing user stories
- There is no end to the process of implementing user stories
- User stories are a negotiation of problems and solutions
Mechanical artifacts such as buildings or industrial products cannot be created using the approach of agile user stories. Understanding the nature of problems and solutions used by architects and designers coupled with the concept of user stories can result in creating very powerful software designs.
How Designers Think
Most of the ideas in this article are from Chapter 7 of the book, ‘How Designers Think’. The book has many other ideas about design and problem solving which are applicable to software development. The author of the book, [7], has a unique background which accounts for his insights — he is trained as an architect as well as a psychologist. Lawson has conducted research in design for decades. He has also collaborated with other eminent researchers in design. He has published many research papers and books. His most recent book is, ‘Design Expertise’.
- Lawson, B. R., (2005), How Designers Think, Fourth Edition
- Page Rank Algorithm, Wikipedia.
- Figure 3.1, A map of the design process according to the RIBA plan of work, Page 35, Lawson, B. R., (2005), How Designers Think, Fourth Edition
- Weinberg, Gerald M., Quality Software, Volume 1, How Software is Built, Section 1.3
- Eberhard, J. P. (1970). We ought to know the difference. In Emerging Methods in Environmental Design and Planning. Cambridge, Mass, MIT Press, quoted on Page 56, How Designers Think (2005), Fourth Edition
- Page 56, Lawson, B. R., (2005), How Designers Think, Fourth Edition
- Bryan Lawson’s biography on the University of Sheffield.
Originally published at https://www.linkedin.com.
