Empathy through

Raising the Bus Factor with Empathy and Sympathy

2014-11-09T00:00:00-08:00

Key takeaways

Make every deliverable maintainable by someone else on your team
Deliver small bits of maintainable work often
Anything that is not maintainable should be considered debt or of no value
Approach the maintenance of your deliverables with the same empathy as any other product

Background

In software development, an important (if morbid) metric for organizational resilience is the “Bus Factor” of a project or product. In short, the bus factor of a project is how many developers would have to be hit by a bus for the project to fail. Of course the bus factor is applicable to many other parts of business outside of software development. My background however is primarily in software development, so this article will focus on that, but perhaps you can glean some general principles to apply elsewhere. Also, please don’t get hung up on the horrific bus scenario. There are many less dramatic (and traumatic) situations where bus factor should be considered. For example, an employee exiting a company for a new job, because a family member was sick, et al.

It’s generally considered better for the organization to have higher bus factors on projects, but it’s also beneficial to those working on the project. If you become the go-to person on a project and it can’t succeed without you, you’ll be on the hook for that project as long as you work at the company. You’ll have a much harder time transitioning to new projects and growth opportunities. If you leave, you may also be dooming the project, which besides not being a great feeling, may leave you with little to point to as an accomplishment in the future.

This post offers motivation and strategies for making your projects more maintainable.

Maintainability as a product

So much of our effort in software and product development is centered around the functionality for the end user. Does it fulfill the user stories? Does it meet requirements? If so, we often ship and consider the job done until the next round of user stories and requirements.

But there is another set of people using the product: its maintainers. This group might include the original creators and it may include others who come on later, but they are nonetheless impacted by the product and deserve the same level of empathy as anyone else. So let’s try writing some user stories for them. We’ll use the common phrasing, “As a <persona>, I want to <action> so that <reason>.” As you’re developing the product, evaluate the current state against the user stories you’ve written for it. See if you have all the artifacts necessary to execute the user stories successfully.

As a new junior developer on the team, I want to find where some inefficient queries are being made so that I can optimize a page.
- Let’s assume we have a traditional Rails application where the view is rendered by the server and it uses ActiveRecord models in the usual manner. If the junior developer searches for Rails documentation and finds the conventions it uses, he or she might be able to go directly from a slow query log to the code in the model or controller that formed the complicated query and edit it. In this case, simply using well-documented, industry-standard conventions was sufficient to resolve the story.
As a seasoned developer who has been on the project for a while, I want to understand our product’s current plugin architecture so I can resolve an issue with load ordering that confuses some users.
- In this story, say we have developed a custom plugin architecture for our product. Hopefully, there is documentation for the user which explains the interface. The output of the “resolution” of this issue may be more user documentation or code changes to make a more natural load ordering. In order for the developer to begin solving the problem, is there documentation or a comment that explains the background architecture? Can this developer be expected to know where to find it? Does it describe the load ordering? Whatever the cost to get to this understanding is the technical debt to resolve this issue.
As a product manager, I want to understand the technical reasons for a privacy issue discovered in a bug bounty program so that I can explain the problem to users.
- Does your product have documentation on how it deals with sensitive personally identifiable information (PII)? If not, then resolving this issue will require a developer to dig into the code and figure out the issue. This cost may be acceptable to you and your organization, but then you have another maintenance user story for the developer. Does that developer then have everything he or she needs to find out the issue quickly?

Notice in the user stories above (as with most user stories), the personas are key. The requirements for a product manager to resolve an issue are very different from those that a developer faces. But both parties (and others) are involved in the long-term ownership of the product and deserve attention.

The stories that I’ve presented here are somewhat specific and you might imagine that coming up with such stories before creating a project is difficult. That’s absolutely true, but it doesn’t mean you can’t or shouldn’t do it. All of these problems can be imagined by those with experience and empathy for the future maintainers. (I define empathy as caring about the situation of someone because you have had a similar experience.) You can practice creating such user stories by looking at the maintainability of your current products and writing stories for problems you’ve had to solve since their release.

Depending on the user story, you may also be able to use one of the three interaction types I describe in a previous post, Empathy, Sympathy, and Compassion in Product Development, namely customer interviews, customer observation, and doing what the customer does. In this case, replace the word “customer” with whichever persona pertains to your user story. It might be a new developer to the project (an opportunity you may not have often, so take advantage of the person’s unfamiliarity during his or her on-boarding) or the product manager currently working on the product. Even with these interaction types, you may have to rely more on sympathy (concern for someone not based on experience) than empathy for user story development.

Note that the user story formula I used contains an action. If you are writing user stories and evaluating against solving them, you are preparing your product or project for actionable maintenance. In other words, we’re not optimizing for just “getting to know a project” and nor should we. There’s not much business value in knowing a project’s structure without an associated action. Maintainers who are not performing an action will likely not have as concretized knowledge as when performing an action. Moreover, they aren’t actually “maintaining” anything when becoming familiar with a product without a goal.

Lock-step maintenance

Getting back to the concept of bus factor, remember that employee departures can happen at any time or priorities can get shifted to a different project temporarily, leaving a project in limbo until the team can return to it. Thus the bus factor is always relevant. By making maintainability part of the deliverables of each sub-part of the product, we retain the possibility that we or someone else can pick up right where we left off, with a well-understood (but hopefully minimal) level of on-boarding overhead.

The concept of continuous integration (CI) has been around for a while and generally exists to validate the quality of the software being produced with each check in. We could derive an analogous concept of continuous maintainability, but at this point, no automated processes exist to validate the maintainability of a project. We can nibble around the edges of the code with style checkers that look for javadocs and the like, but this approach hardly gets us all the way to the level of automation as exists in continuous integration.

We must, unfortunately, rely on more discipline and the motivation that we are producing something that we can hand off if we want to work on something else. Nonetheless, there is precedent for similar processes; we might have a better analogy to code reviews than to CI to enforce maintainability. In code reviews, by requiring that at least one other developer reviews code before it’s checked in, we can catch mistakes and evaluate the comprehensibility of the code. There’s certainly a benefit to maintainability here as well. However, we need to go further to ensure specific maintainability features.

Staying within the framework of code reviews, try assigning a developer with no context on your commit to review your code and give him or her no direct primer on the project. Are they able to jump in and see what issue your code is addressing? Do they come up with the same broader architectural concerns as developers familiar with the project? The ease with which he or she is able to understand your commit is likely proportional to the maintainability of your project.

Note that a large commit will likely be less comprehensible to this developer and that it will take him or her a long time to get up to speed to understand it fully. This difficulty may happen when you ask him or her to do this code review, but think of what will happen in the future when someone maintaining the project comes upon this commit. In addition to facing the size of this commit, he or she may not have you around to explain it. Even if you are around, you may well have lost the context yourself. In other words, keep your commits small, focused, and well described to support maintainability.

Remember that non-developers are required to maintain your product as well. For product managers, it may be their role to review documentation (especially internal) before each release to validate they understand the product sufficiently. QA may also be a valuable source of information as they discover issues with the product.

Maintainability via empathy and sympathy

In this post, I’ve suggested that we treat the maintainability of a product as a product in and of itself. Use your experience (or at least your imagination) to empathize or sympathize with those who will maintain your product after you’ve departed it, either for something in the same company or not. Your goal should be to get those maintainers up and running quickly and independently, just as you would have liked when working on someone else’s product.

Raising the Bus Factor with Empathy and Sympathy was originally published by Emil Ong at Empathy through on November 09, 2014.

TDD as a Practice in Empathy

2014-11-04T00:00:00-08:00

Key takeaways

Writing your tests first is using the code before it’s written.
Listen to your experiences while using your own code. You are the first user.
Make sure your code and interface deliver clear value to the user.
If you don’t want to use your code (i.e. write tests), nobody else will either.
The size of test code scales with the versatility of the code, not the size of the implementation.

Definitions and purpose

Test-driven development is often summed up as “write your tests first, then your code.” There’s a lot more subtlety to the practice (as we shall discuss here), but this epithet is often all that’s carried forward. This reductive description thus leads to misunderstanding, code and tests no better (or possibly worse) than before hearing about TDD, and often ultimately discarding the practice.

This post attempts to explain a purpose and practice of empathetic interface design while using TDD. I define empathy as understanding of someone else’s situation that you’ve developed as a consequence of experience with a similar situation. The key point of empathy (at least for the purposes of this post) is experience.

Tests first

When you are writing your tests first, you are using the code you are about to write. You are defining the interface from the perspective of the user. You are gaining experience using your own code. If you are attentive to your own aches and pains during this part of the process, you will know how the users of your code will feel in the future. If you are delighted in the interface, well, at least someone else has a better chance of being delighted.

Classical/pure functional code

Functional units of code (in the sense of functional programming) are much easier to reason about both for users and for purposes of testing than those that require dependency injection or side effects. This statement is not made to say that those approaches are not useful, but you must balance the benefit you get from those patterns with the ease of comprehension of the code.

To give yet another reductive definition, functional programming is when you have a defined input which totally determines the output.

Best case scenario

In the context of an interface and testing, you know:

what you’re sticking into the code,
where it goes,
what comes out of the code, and
where it comes from.

This is a wonderful situation and it’s the code that most people would be happy to use because the transaction is clear. I give you something I have, you give me something I want.

Overpricing

If your code requires a lot of inputs to do what it needs to do, this is the picture a user gets when they approach it as an interface:

The setup for this code becomes painful and the transaction just became totally lopsided. As a test writer, you wrote a lot setup to validate a simple assertion at the end. It sucks. As the user of this code, you just did a whole lot of work to get very little out. The output better justify that work.

An embarrassment of riches

The transaction imbalance can swing wide the other way as well by giving a lot of output for not much input.

In certain contexts, this might be a nice scenario as you’re giving the user “extra value,” but in most cases they probably feel like they’ve just bought a massive variety pack at the warehouse store and are digging through for their favorite flavor. Testing all of these outputs is also a pain in the neck and looks like a checklist of a ship manifest.

Common forms of this pattern include:

A function returning an array or map with multiple values
A data object or struct with many fields and/or deep nesting

There’s also a danger in losing empathy with your users in situations like these. If your output can be used for so many purposes, it becomes harder to focus on solving any one of the problems. Is it easy for the user of output 5 to get the right input? If not, they may not be well-served by this code while the user of output 2 loves it, but never uses output 5.

Pattern example: Dependency Injection

Let’s look at applying a pattern, namely Dependency Injection (DI), for more complicated/structured code and how we can apply empathy in our application of it. Dependency injection can help the user when they don’t need to know how the code should be configured or are passing in redundant inputs all the time.

Best case scenario

The diagram below shows a situation where we pass in an input and a dependency to the code with a single, direct output.

This picture is simple but gives us the additional flexibility of configuring the code. We have two knobs and only one output. To use this code, we use the following pattern:

Setup: Create an object, closure, or other mechanism carrying the code and inject the dependency.

Use: Provide an input, receive an output. User disregards the dependency after setup.

Your tests look exactly the same. Your user has struck a great bargain - for a little bit of setup, they get an effectively functional piece of code that works in many scenarios.

Dependency overload

DI code can experience both the problems of input and output overload as in the classical functional examples, but they also may suffer from dependency overload.

Here we see that while the cost of setup is quite high, the use of the code remains straightforward. As a consequence, you might say that there’s still a good bargain being struck here, especially if the user employs this code in a high transaction situation. This might be true, but try writing tests for this code. You only have to set it up once, just like the user, and you might then be able to test multiple inputs based on the dependencies. But was it painful to setup? If so, your users might be driven away from your code because their first impression is one of a painful setup, no matter how nice the payoff in the long run.

Test size versus code size

Some complaints about TDD include that it can lead to over-testing and that the tests often end up bigger than the code. I’d venture a hypothesis that this feels wrong to some people because we intuitively expect the tests to be proportional to the size of the implementation, but this isn’t quite right. The size of test code scales with the uses and versatility of the code, not with the size of the implementation itself.

This isn’t to say the intuitive understanding of the size of test code is totally off; code is often as useful as it is long. But this certainly isn’t always the case. Some small functions can be extremely versatile and require a large number of tests to expose their various different workings. Some large code can be pretty limited in its application, but provide great value in those cases. It’s case dependent and you must revert to your empathy in using your own code to find the line between what should be considered too many or too few tests for the unit under consideration. Remember too that you may have the option of refactoring the interface to make the unit’s purpose clearer and/or more concise.

Conclusion: Empathy for the TDD practitioner

I wrote this post out of empathy with you, the TDD practitioner. I know it’s hard to start down a path of TDD and in the initial stages, it requires discipline. But perhaps by understanding the empathetic aspect of TDD, you’ll see it through and become a great practitioner or even find a better way for the world to write great code and interfaces. By building code that you want to use, you’ll begin to build code that others will want to use as well.

cf.

David Heinemeier Hansson’s (a.k.a. DHH) arguments against TDD are often quoted by folks who’d rather not practice TDD. I’d encourage any experienced developers to read his posts TDD is dead. Long live testing. and Test-induced design damage because they contain valuable insights about how he came to form his opinion. Two factors dominate, from my reading:

He felt bullied into practicing TDD and dogmatic developers made him feel like TDD was some shining light for every situation.
He wants well-designed code that isn’t littered with test injection points and TDD was not doing this for him.

Hopefully experienced developers can appreciate both points. It’s ridiculous to bludgeon people with a methodology when you can’t actually show how it provides value. If your reaction to someone not practicing the way you do is to shame them, they aren’t going to practice it for very long when you’re not there looking over their shoulder or yelling at them.

We all want well-designed code. Implementation code that exists purely to support tests is also pointless. The tests you are writing to use your code should look like how you expect your code to be used. If you have to bend over backwards to use your code in tests, so will your users, if you have any.

This is not say that I agree with all his points and certainly not his conclusion, but I’d encourage anyone practicing or considering practicing TDD to read DHH’s experiences and find their own path.

TDD as a Practice in Empathy was originally published by Emil Ong at Empathy through on November 04, 2014.

Empathy, Sympathy, and Compassion in Product Development

2014-10-19T00:00:00-07:00

Key takeaways

Empathy requires direct experience, sympathy does not, but both are valuable
Iterate to gain experience, being mindful to gain empathy and/or sympathy at the same time
Utilize sympathy in at least your first (or first few) iterations to get started
Empathy, if not rationalized in the business process, can lead to an overfitting solution with little business value

Purpose

Empathy has lately become a popular word in a number of fields with which I interact, including design, data science, engineering, and product development/management. Its benefits are extolled as creating more meaningful products and services, and thus ultimately more successful and valuable ones. However little advice is given about how to acquire and employ empathy in your practice. This article will focus on product development, attempting to give a theoretical structure and practical tips on empathy, as well as the related topics of sympathy and compassion.

Definitions

The definitions I offer below may differ from your understanding of these words, but I set them out to give a name to the topics I’d like to address.

Empathy is understanding the situation of another person via similar experiences in your own life.
Sympathy is understanding the situation of another person via imagination.
Compassion is caring about the situation of another person.

Reflecting upon these definitions, the common phrase I use is “the situation of another person.” What this usually means in world of product development is the problem that the person it trying to solve. However, there may be a number of components that we want to consider:

Demographics including age, gender, race, nationality, etc.
Limitations including economic, geographic, available services, etc.
Disabilities be they physical or mental
Personality types such as introversion/extroversion, creativity
Experience, especially as it relates to the problem they are attempting to solve

With these definitions in hand, let’s see how they fit into a product development process.

Product Development Process

Many different product development processes exist, so I’ll use my own (or at least my ideal process :D) as a template to talk about where empathy, sympathy, and compassion fit in. My process is akin to agile methodologies, though I won’t claim that it’s a capital-A Agile process. You may find similarities to Lean Startup, Customer Development, and simply the scientific process as well.

The process is as follows:

Find and state a problem.
Hypothesize a solution to the problem.
Build your product.
Measure the effectiveness of your product.
Refactor and repeat.

Let’s dig deeper into each step and see how their tactical execution is affected by empathy.

Find and state a problem

This step is probably the most important for empathy, so I’ll be dissecting it quite a bit more than the others. Specifically, I’ll deal with the “find” and “state” parts of this step separately, as they each deserve their own attention.

Looking for problems

Let’s break down some of the different ways that you might discover a problem.

Discovery method	Advantages	Challenges
Encountering the problem in your own life or work Noticing someone else in your life struggling	These examples are great ways to approach a problem because they have empathy built in. You are close to the problem and are thus trying to solve it for you or someone you know. These situations are classic and make a great story. You likely also have compassion for other people trying to solve this problem because it's one you face as well.	It's easy to be too close to the problem in these situations. What that means is that your experience may differ from that of other people facing the same problem. Thus you need to be very careful either to limit the target of your solution to people in similar situations, sympathize with others in different situations, or gain experience to empathize with others in different situations. Moreover, if your experience is specific to you or a small set of people like you, your solution may not have much business value.
Being asked to work on the problem by someone you know who was already working on the problem Sitting down to try to invent something or identify problems in order to start a business or find value	You have detachment from the problem, so you can approach it and the people it affects more uniformly. You must still have compassion (and ideally sympathy) to get started, but you have the opportunity to dive into the process and address the target group that presents the most business value.	You might not have any experience in the problem you're considering solving, so you cannot have empathy (yet). So you need to have compassion in order to have any chance of success.

The second two discovery methods are, at least in my experience, more common ways of arriving into the development process. You might have joined a startup, been assigned a project at work, or just been looking for problems so you can make money. You often have to have the problem described to you for you even to understand its existence, much less its nuances.

Just to sum up compassion in these examples above, you need to care about solving this problem for people, even if you don’t share their experiences. If you don’t, your ability to gain empathy or sympathy is heavily diminished and along with the chances of your success. You don’t have to care about every problem, but you also do have to work on every problem either; you might look to solving something else.

Problem statements

The statement of the problem is highly related to finding the problem. My technique for this is user stories which take the form of:

    <persona> wants to <goal> so that <reason>.

User stories are a key part of the process where empathy and sympathy play a part. First, defining personas is important because you need to know who you’re talking about to empathize and therefore understand that person’s wants and reasons. A former colleague of mine used a process with sticky notes where we actually drew a face and gave a name to help make the persona real and relatable. Be as specific as is reasonable to start, then group later.

From strong personas, especially those with whom you empathize or sympathize, the goals and reasons often flow easily. If they are defined in such a way that you can identify with them, you can usually see the problems from their vantage point. One thing to note is that the outcome of the story should always end in value for the persona. This should be objective value in the form of money (e.g. in the case of business products), time (e.g. reducing the end-to-end time in something they’re already doing), or something else measurable. A general feeling of wellness, reducing anxiety, et al. are vague and not provable.

Gaining sympathy and empathy

Until now, I’ve discussed how empathy and sympathy are useful (or dangerous), but not how to gain them during your process. Let’s look at some techniques and how they can help.

It’s common during the first step (finding and stating a problem) to do customer interactions to find out what customers are facing, their requirements, etc. This usually takes the following forms:

Interaction type	Commonality*	Gainable Empathy	Gainable Sympathy	Notes
Customer interviews in which you ask customers about their problems and current approaches.	Enterprise & expert products	Low	Low	One of the great benefits of interviews is that they offer the chance to ask how customers feel about approaching the problem. Their feelings are potentially less observable in the other two interaction types. However, there's the notorious problem that interviewees often say and do different things. In a sense, they can at best sympathize with themselves!
Customer observation in which you watch customers go about their business and you see what issues they run into and how they try to solve them.	All	Low	Moderate	You have a much better chance of actually seeing and relating to the customer's actions as he or she encounters the problem with this approach than with interviewing. There are the usual warnings here about observer bias, the subject changing their behavior if they know they're being observed, etc. For the purposes of this discussion though, note that you're still not directly experiencing what they experience. Considering sympathy however, you probably have a better chance of seeing something relatable than in an interview scenario.
Doing what the customer does to find out how, from a first hand perspective, what the problems and current tools feel like.	Consumer	High (with caveats)	High	If you do have the opportunity to walk in the customer's shoes you're more likely to gain insights as to the nature of the problem. Be careful that you're mindful and understanding what you're gaining during this experience however. If you're targeting skilled craftspeople with years of experience and trying to make a better tool for them, you will not gain the experience they have on a daily basis with tourist stint. You may however gain valuable sympathy.

There’s also the hybrid interview approach which deserves mentioning, specifically that of asking people how they feel and what they’re trying to accomplish while either observing or taking part in their activity. It especially may impose observation bias, but can get to both feelings and action simultaneously in the best case.

Commonality above is of course based on my experience and YMMV. The empathy and sympathy columns should not be taken to mean that you shouldn’t do interviews or observation if you’re also doing what the customer does. All have their place and contribute to a holistic understanding of the customer’s experience. Use as many as you can, especially if they’re not common in your market segment. For example, if you’re developing a product for enterprise users, your chances of doing their job may be small, but it’s likely to be hugely valuable.

Hypothesize a solution

This is the step where you take what you learned in stating the problem, combine it with your cleverness, ingenuity, and outside experience to produce the statement of a possible solution. But don’t jump right into building just yet. Building is expensive and you can use your learnings to do some sanity checks on your hypothesis. You will now usually go back to customer interviews mentioned in the previous section to see if it’s worth proceeding. You can also imagine yourself in the shoes of the customer, but now armed with this hypothetical solution. But be aware that both you and the customer are trying to sympathize with your future selves. Neither of you can have empathy with the solution because it doesn’t exist yet. That’s why you have to build it…

Build the product

Empathy and sympathy of engineers toward the customers is important, but if the problem and hypothesis are well-defined, their main function should be sanity checking during the building process. In other words, the engineers should be keeping their customers in mind the whole time and validating that the product meets the user stories and use cases and alerting the product management when things aren’t going as planned. Outside of that function, engineers should be focusing on solving the problem to the specification of the hypothesis.

Measure the effectiveness of the product

Now that you have your product, it should be possible to validate whether it solves the problem you stated in the first step. Again, you can go about this with the customer interactions mentioned earlier. You can provide the product to the customer and observe them using it and you can use it yourself.

The results of each are the same. You have a good opportunity for gaining sympathetic understanding with observation. You may gain empathy or sympathy by using the product yourself. The value is the difference in experience between when the customer didn’t have the product and when they do.

Note that the practice of “dogfooding,” using your own product before release, must be conducted with care and a mind toward the highest empathy/sympathy gains. All too often, we use the product like builders of it rather than as customers.

Refactor and repeat

By this point in the process, you should have gained some additional insight on the customer, their process, and the effectiveness of the product than at the beginning.

You

During this entire article, I’ve addressed you as a product developer, but using all of my own experience. To get a bit meta, I’m using empathy and sympathy about the product development process to give you a product (this article) to help you improve your process. Some of this may not apply to your experience, your team, or your product, but I hope it’s been helpful. I’d like to emphasize that sympathy is incredibly valuable, especially when shared experience (and thus empathy) is not available to you, for example in cases where you are in a completely different demographic than your customer and that demographic is relevant to the problem. However it’s key that you interact with the customers and potentially have someone who can empathize with them on your team.

Postscript

To be honest, in the entire article I’ve taken it as given that empathy and sympathy lead to better products. There’s certainly an argument that they do not need to be present in all parts of a business to be successful, but I think an argument in favor of them in product development might look a little like this article anyway. I might address this in a future post.

Empathy, Sympathy, and Compassion in Product Development was originally published by Emil Ong at Empathy through on October 19, 2014.