Why Empathy is the Secret Sauce for Good Software Development
“Typically we’re creating tools for other people.”
We know empathy is a necessary human emotion. But is it necessary for good software? If you’re developing software for humans or even alongside other humans, then, yes, it is.
As a software consultant and agile coach Daniel Bryant is often brought in when things are going awry — and he says usually human interactions are at the heart of the issues he is paid to solve. He sits at the crux between technology and teams, but it’s usually the human interaction side that needs optimizing.
At a recent Meetup in London, Bryant presented his case for empathy. But he quipped that, when he mentions “empathy,” developers often ask if that’s a hot new programming language.
“People are so locked in on the technology that I have to say, no no, think about your actual customer you’re developing for, your teammate, your boss, even that Internet troll — dare I say it. It’s super important to be able to put yourself in their perspective and think and feel what they think and feel.”
Empathy is a logical place for user experience testers to start, but developers? Really?
“We’re typically developing software for other people, with other people to create an experience.”
Bryant says the development process is and should be an emotional one. “Even if you’re working on a standard business application, fundamentally you want your users to enjoy — or at least not hate — using your software,” he said
For him, empathy is the secret sauce covering all good software development. So what exactly is empathetic software development? How can it be applied to both how we serve customers and our fellow teammates? and How does it fit into the whole world of the agile development process?
Hint: Rapid iteration and continuous feedback are always important.
Where is Empathy Found in Code, Anyway?
Bryant says empathetic software development comes from the source of all empathy — understanding people’s experiences and feelings. Differing from sympathy or compassion, it involves being able to engage with someone emotionally and to put yourself in their proverbial shoes.
This also comes down to the core principle of knowing yourself before you can know others. Then you can make an effort to know others and to seek to learn from them, with rapid feedback, by using agile, lean or DevOps practices or a combination of the three.
After all a 28-year-old guy won’t be able to properly develop a device meant for a 70-year-old woman all by himself.
One key point Bryant made is that apathy is the natural opposite of empathy. So if you want to build good software, you have to care about what you’re doing and who you’re serving.
He offered three examples of where empathy enhances any software development process.
1: Requirements Gathering
Requirements gathering is all about asking why. What is the impact for you? What is the impact for your business? What does your team want to have?
Bryant says design thinking and understanding the whys driving is making the conscious decision not to just lay on function after function, but sometimes even pairing back for a better user experience.
One way to reach these conclusions is by creating an impact map, which asks the following questions:
- Why? Define a business objective.
- Who? Name the key personas you’re building for.
- How? Describe the desired change in behavior.
- What? Find users that allow these desired changes.
The Who is where empathy becomes a valuable asset. You can try to follow the marketing practice of creating user personas, as a way to represent large user groups and their respective needs and expectations.
He says this is particularly a great way to uncover universally desired features.
The most accurate way to achieve these profiles is by interviewing your different clients, which is a great way to build empathy. However, typically, they are generalizations made from what you know of your users. You can also find a lot by using app analytics tools and Google Analytics to find out where your users are coming from and what tech they are using your tool on.
“To be empathic takes effort, but it’s worth it,” he said, though admitting that user personas can be time-consuming.
Bryant places empathy mapping as a more cost-effective way to create personas in less time. 
This exercise first talked about in “Gamestorming,” a book about fostering innovation, starts by putting the name and title or even a pic of a known customer on a wall. Have everyone in the room mark up stickies of what you think that persona is seeing, feeling, hearing, and the like.
Don’t know your customers that well? It’s time to get out of your cubicle and into the wild!
This is all part of ethnography when you actively work to connect with your customers where they are. Bryant gave the example of Not On the High Street, the U.K.’s answer to Etsy, which went out of their way to empathize with their software partners, including warehouses and shipping.
“They could identify with consumers because they had shopped there, but they couldn’t identify with partners. So they went and spent a day in the warehouse to learn what the people did and how to use software,” Bryant said.
He says this is the way you can witness first hand the highs and the lows. And since it was just coming on the rush of holiday deliveries, the developers really started to understand how much those little things could cause big messes during peak season.
As we move toward a world of connected devices, the software we’re creating will be more personal, even on or inside our end users. In the Internet of Things, this connecting with the users will become even more essential. After all a 28-year-old guy won’t be able to properly develop a device meant for a 70-year-old woman all by himself.
It’s all about prototyping and even just sketching ideas and going into the actual environment, talking to those future users, to get their ideas and feedback, before you go making something they will reject.
It all comes back to the agile fast practice of “build, measure, learn” — you have to be close to the customer to do that effectively.
2: Architecture and Development
For Bryant, architecture is fundamentally about a shared understanding with your developers and appropriate risk management.
For the first, he says team leads must also code in order to gain understanding of your own team.
“The right constraints can set us free, but you have to be able empathize with the people you’re setting the constraints to,” he said.
And he says all risk management involves identifying with the stakeholders.
“We all love the shiny new things like microservices and containers, but it all comes down to whether it is right for us and our situation.”
That’s why it’s important to mitigate risks instead of jumping into a shiny new architectural framework. Bryant recommends Matt Raible’s Comparison Matrix to remove some of the subjectivity by scoring each thing on its own criteria.
The Comparison Matrix puts that decision-making record in place. When he walks into software companies, “It was like that when I got here” is the most common reasoning.
And things move pretty fast in development. Sometimes we don’t even remember those whys six months to a year later. This is why Bryant advocates for coding in a way that empathizes with your future self and future colleagues. If all code is a form of communication between the past and the future, an important relic of our generation, we need to strive for cleaner code, with proper documentation, READMEs and Wikis.
Then, he shared Coding Horror founder Jeff Atwood’s memorable line: “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.”
That’ll certainly have us thinking about documentation more, won’t it!
Empathetic architecture also touches on systems thinking, which encourages self-organization and has those in more managerial roles focused on examining the interactions between components of a system. Understanding the user journey is often a disregarded component of that system.
Empathetic systems thinking also implies shifting left so that QA and testers interact with end users and they are a part of the specs early on. This is sometimes called the three amigos — always have at least one developer, one QA, and one product manager on any product team.
“I find people working in QA are a bit more empathic than developers typically,” Bryant pointed out.
This, of course, leads into behavior-driven design (BDD) and test-driven design (TDD). Bryant recommends working from the outside in, focusing on big picture then drilling down to specific features.
Finally, he said the core themes in successful architecture and development are:
- Knowing yourself and checking your communication skills: Is my code making sense?
- Knowing others: Understand the whole system and be solutions-focused, thinking from the outside in.
- Seeking rapid feedback via prototyping.
3: Operations
Bryant says operations is the part of a software team that tends to get the worst rap in terms of empathy, but everyone has to be responsible for the products they are turning out. That means breaking down silos, not tossing software over the wall to operations. It’s about sharing the pain
Bryant also shared Mary Poppendieck’s Regulatory Fit Theory which pegs developers as more into promotion and features, which DevOps are more focused on prevention.
Netflix is particularly good at sharing the pain — or wearing the Pain Suit as their developers call it — where everyone is responsible and has a holistic understanding of their complex microservices architecture.
“We want to understand in real time what effect a variable is having on a subset of request traffic during a Chaos Experiment,” the Netflix “Traffic Team” collectively shared on the company blog.
Agreeing with Netflix, Bryant talked about a theory of how safety features like airbags and seat belts certainly save lives but they also make a small percentage more reckless. They wouldn’t be so reckless if there was a spike next to the airbag. He says the occasional spike to the head that has developers waking up is having developers “on call” with accountability and shared responsibility for deploying. “You build it. You run it.” If it falls over in production, you should be responsible for fixing it.
Perhaps this isn’t the most popular idea, but one that Bryant assures has to happen.
In order to have more developers falling on the proverbial spike, you need to make sure that DevOps isn’t a separate department. Pair Devs with the Ops, and treat operations as stakeholders who even join your daily standup and planning meetings. It’s important to have as much face-to-face interaction as possible.
Then automate the most important bits of testing, giving anyone developing within the code the alert to any bugs, so the first person who discovers it — often the developer — should fix it. Semantic monitoring is application testing that you run continually while your application is in production.
Bryant says to avoid alert fatigue, focus on the most important things for your customers. The database might be down but there may actually be no impact on customers. Empathizing with your users is about being able to identify what is a problem and what isn’t.
For example, in an e-commerce site, there are only three things that are critical to success — can you browse for products, can you add items to your basket, and can you check out. Other things that break — like can you sign up for a mailing list — are important and will eventually need to be fixed but aren’t essential tor the bottom line.
Empathy in software development is about the balance between freedom and accountability.
