In this interview, Heidi Waterhouse discusses the topic of her session "Seven Righteous Fights". What are the 'Seven Righteous Fights' in software development? Heidi talks about the need to challenge assumptions and actively allocate resources for better user and developer experiences. She also explains how addressing these fights early can help mitigate technical debt and long-term challenges in software development.
Your talk is named "Seven Righteous Fights". Who or what are you fighting and why?
All of us have a tendency to assume someone else has made a real choice to have something in some way or another. That is the tendency that we need to fight. We need to ask questions about how we're allocating our finite resources and if that represents where we want our product to go. We are fighting inertia and passive acceptance in pursuit of better user and creator experiences.
Could you share an example from your experience, where addressing one of these fights early in a project had a significant positive impact on the project's outcome?
As a technical writer, I was writing and editing the user interface strings. I advocated for us using the EN string identifier, instead of hard-coding English into the product. When we decided to localize to a second language, we already had a way to read language strings instead of needing to take the English out and put it in a new string. It was relatively easy to make that change in the beginning but would have been harder and more expensive if we had needed to do it at the time of localization.
You mentioned the compound interest of technical debt. Could you explain how addressing these seven fights early in development helps mitigate technical debt and the long-term challenges it can introduce?
It's almost impossible to address all seven of the righteous fights as early as we want. However, the earlier we start thinking about them and pre-planning, the better it is. Just like debt interest can compound, so can asset value. For example, creating accessibility accommodations early in a product, before you have users asking for them, may not seem to make business sense. However, making it possible for users to engage with your product may open up markets that you weren't originally planning on, or that your competitors can't reach the same way. Even small changes to your early product design and thinking can have long-term beneficial effects because you won't have to retrofit changes.
The larger your codebase and the more mature your product, the more known and unknown dependencies will exist. It's very easy to make a change in a few hundred lines of code, and relatively difficult to make a change in a few hundred thousand lines of code, even if the change seems to be the same. The larger codebase involves more people, more dependencies, and more interactions, so it's harder to predict and test whether the change is going well.
One of the principles of the Agile Manifesto is: “Simplicity – the art of maximizing the amount of work not done – is essential.” Why is it important to put work into these seven points so early on? Isn’t there the risk that this work is done in vain, e.g., because we did not go international after all, even though at first we thought we would, or the API remained internal, even though we were convinced others would need it too?
There is absolutely a risk that you would do unneeded work. It would be poor planning to create an entire feature that was not useful. Agile exists partially in reaction to the times that we planned out a whole product, and when we finished it, found it wasn't what was wanted or needed. The faster feedback loop helps product owners and developers stay honest about what features add value for users. But while agile development is a revolution, it's an incomplete revolution. Sometimes we need to do work that is not feature work or is not going to be immediately visible. Systems work and future-proofing is hard to fit into a pure-agile development style. I think the trick is balancing those competing values. You mentioned working on an API that never goes external, but internal developers are still using it, and having a better interface for them also improves the product.Maybe the larger question is not "How do we avoid building something we don't need?" and is "How do we make any effort allocation mistakes as small as possible?".
Many organizations struggle with balancing the urgency of delivering software with the need for quality and sustainability. How do you recommend teams prioritize these seven fights within tight project timelines?
So much has been written about speed and quality that I feel like this deserves a whole essay. The short version is that we've studied it, and delivering quickly and well is not in opposition. _Accelerate_ and the DORA report demonstrate that smaller, lighter, faster releases result in less downtime and happier teams. The way we fit these seven practices into that structure allows for iterative improvements without needing to make it a massive commitment. Even a small improvement, repeated regularly, can make a big difference.
Sponsoring a conference is a terrific way to support and connect with our global community of software architects.
