Empathy Driven Development

A primer on designing software with a primarily empathy driven approach.

Almost any notable accomplishment will need to be done with the help of others, and engineering software is no exception. Software is also constantly evolving and needing to be maintained and adopted for new use cases after it has been released into the wild, often by engineers other than yourself. We can make this evolution process easier for ourselves and our fellow engineers by practicing the methodology of Empathy Driven Development.

Empathy Driven Development (or EDD for short) is an approach to software engineering that prioritizes the design and implementation of malleable, maintainable, and comprehensible software systems via intentional and mindful collaboration with other engineers. Actively seeking the feedback of other engineers is the best way to ensure your design decisions can be understood and built upon by others, and exposing your ideas to people with perspectives different from your own can help to uncover edge cases and other use cases that can be dealt with proactively before they reach users in production.

In my experience, there is a clear difference in quality between systems designed with the EDD approach versus those that are designed with a lone-wolf approach, with the systems being developed with EDD being much more stable, easier for engineers to maintain and add features to, and less likely to undergo major refactors when it comes time to incorporate new use cases.

There are a number of tools and processes your team can incorporate to encourage practicing EDD in their every day work. One of my favorites is documenting any proposed changes before digging into code, and having your peers review it and leave comments and questions about stuff they are unsure about. This documentation can be as informal as some scrawl on a whiteboard or as formal as a full-blown technical design document with a table of contents. The main idea is to make sure the systems you are designing are easy to digest and comprehend by others.

You can also practice EDD while writing code, such as by using clear and concise variable and function names, writing comments to document the intended use cases of modules and functions, and providing any supporting documentation that can aid in maintaining and debugging your code. Pair programming and code review are also great tools for getting the perspectives of your teammates on the code you are writing and will be sharing the maintenance responsibilities for with.

The goal behind these different tools is to better ensure what you are building will not become a burden that your teammates will need to carry, and that eats up valuable sprint time for building cool new things because everyone is too busy trying to understand and fix your bad code.

However, all of these tools are moot without first having established team psychological safety. Psychological safety is necessary for engineers to feel safe to bring up issues in each other’s designs and admit when they don’t understand something or disagree with someone else’s approach. Fostering psychological safety is a topic unto itself that is out of the scope of this post, but if you’re a manager wondering how you can do this for your team, I highly suggest you check out this guide from Google.

We all strive to write “good” code, but often fall back to just getting something, anything working out there, due to upcoming (and most likely artificial) deadlines or some other newer priorities. There is always the option to revisit and refactor, but that almost always gets pushed off in favor of shipping new functionality, often times on top of the shaky foundation of a poorly designed system, which in turn makes the underlying system even more technically and politically impossible to refactor as it becomes entangled with newer functionality. This can result in newer features taking longer than necessary to implement due to needing to work around poorly designed and written code. We can instead do ourselves and our teammates a solid by always asking ourselves how our actions and the code we write and ship will impact those around us, and how we can make their lives a little easier.