Solving the customer’s problems
A strange development occurred in architecture, whereby the involvement of the client diminished as the cost grew. You might think that someone who spends a lot of money on a project would expect to have a great deal of sway on the decisions made, but they often tend to lean towards the opposite outcome. As the cost increases, the time the architect spends consulting with the client diminishes. This reduction of influence is now expected, to the extent that Christopher Alexander was told by his clients[NoO3-05] that they were thrilled to be as involved as they were in developing their own homes. They expected his team to present them with some beautiful final form rather than taking considerable time to gauge their constraints and elicit from them all their deepest hopes and desires for their investment.
In some ways, agile development attempts to parallel this building process. There is a preference for taking a route where you keep the client in the loop, and returning to them with prototypes and mock-ups to get feedback aligns with Agile principles. However, all of the agile methodologies ought to incorporate the practical, concrete practices of Christopher Alexander when extracting those elusive, profoundly human needs. I’m not talking about the problems caused by emergent properties—those are the constraints of the built product. No, I am referring to the gap between what the customer is willing and able to ask for and what they actually want and need1. Even knowing the gap exists would be an improvement.
In the realm of architecture and building, the patterns found were all of a sort that produced environments for the end user. They cared less for the builder and very little for the ego of the owner of the completed buildings. If we consider a building contractor, a developer who funds and then rents out the building, and a potential family who will live in it for a generation or two, we can easily see the differences between them. In effect, the patterns were all about how the building was to be used in line with the actual lived experiences of the family members, not so much the building process. The affordances to the contractor who built the house tended to be those that were also good for future maintenance or for when the family wished to extend their home. In almost no instances were the patterns supportive of landlords or land developers.
As I studied design patterns, I saw an emergent property of these patterns for physical buildings, not just in relation to homes, but with regard to workshops and malls, hospitals and schools too. The patterns were almost always related to two or more of the following states in which people living in and around the building would spend most of their time.
- Rest and relaxation or recovery.
- Sustenance and personal maintenance
- Commuting and transportation.
- Communication and community.
- Labour and the care of others.
- Personal opportunity and spirituality.
- Family growth and adaptation.
These aspects of life required a different approach to building than an off-the-shelf product or modular building technique. They necessitated empathy for the specific needs of the end user. The builder needed to keep in mind the life to be lived by the inhabitants of the space once the job was complete. They needed to probe beyond surface or fleeting preferences and opinions and provide a structured but inviting approach to elicit the deepest, most enduring, and often quite trivial-sounding but fundamental needs.
Equally, an agile software developer needs to have empathy for the client. They must have a clear image of the final goal and should concentrate on how it provides for the user rather than the image the user thought of when they first commissioned the project. The user is an expert in their domain, but they are not an architect or a builder. They do not know how to ask for what they want when surrounded by examples of those requests ordinarily being considered irrelevant, insubstantial, or simply not serious.
In building and software development, the customer or client is, or at least should be, at the centre of the project. Their problems are the only essential problems to be solved. Their needs are the only needs that can be fulfilled and provide value.
Given these principles, the developer’s profit is contingent on correctly pricing effort. Profit can be increased by cutting costs or inflating the client’s investment, yet those actions would subvert the client’s needs or prove the process was not already efficient.
Gaining a solid reputation and taking that to the bank with a constant flow of work was more important when people grew their homes and extended their workplaces. Building was a sustainable practice, not a growth industry. Construction jobs were shorter, and people could gauge your work and hire you again. This is no longer true of physical builders as evidenced by the many attempts to certify trades-folk, so reputation can once again have an impact.
Unfortunately, software development started out in this position. Reputation was nonexistent for software development houses; there was no history to rely on. Those who commissioned software development usually hired in developers as there was such a small selection of large-scale project development organisations.
Nevertheless, we are now heading towards a world where reputation matters because scarcity is no longer a problem for a customer of small apps. The number of software houses that create small to medium-sized applications has grown tremendously in the last 30 years. In this new world where customers will say no, you must be recognised as someone who will solve their real problems and not introduce more as part of your process. We’re not there yet, but the frequency and size of projects developed on a for-hire basis is growing; at the same time, the number of reviews about developers is also rising.
Solving the client’s real problems requires an understanding of how to develop software and how to elicit the client’s deepest requirements. Only when you can find out what the client needs, despite their inability to ask, will you truly develop software that fulfils a need. Only when you have created a car for a client who wanted a faster horse will you know you have developed the capacity to satisfy those hidden requirements.
Some will now think of the quote, commonly misattributed to Henry Ford, about not asking his customers what they wanted as they would have only asked for a faster horse.