• Our Code
• Culture

Refactoring with Empathy

They catapult me back to moments in our history where we have experienced the very worst of refactoring; 2 week estimates that have spiralled into months of burning through client budgets. Months where they see no benefit; no upturn in conversion, no increase in sales, no new features and no user benefit. All they do see is cost. Costs that apparently may make it easier for us to develop their app in the future… but we can’t guarantee it or tell them how much it will reduce their costs in the long-term.

Now that’s not to say that ROI is our only driver, in fact, the process of continuous improvement is core to us. It means that we’re always getting better at what we do, so in theory we could always be refactoring an area of a project whenever we return to it. The question is should we, and when? Here are my thoughts on this difficult and controversial subject (at least in our office). I hope this blog also helps clarify my own thinking on the subject as I write.

What is refactoring?

“Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behaviour. “ - Wikipedia

Essentially it is taking a piece of code and (if you are doing it right) improving it. There will likely be no change to how it works or looks to the user of the software, but under the hood, it has improved. Improvement might mean that it is structured better, has better test-coverage or even uses a different language.

What is empathy?

“Empathy is the capacity to understand or feel what another person is experiencing from within their frame of reference, that is, the capacity to place oneself in another's position.” - Wikipedia

Different people have different levels of empathy and empathy for different people. Within an agency, it is important that we develop empathy in all sorts of areas but in this context, empathy for our clients. We need all our team to be able to put themselves in our client’s shoes and understand their thinking and decision making.

When should we refactor?

In my experience refactoring falls into two main categories and the question will be answered differently in each case:

Large, wholesale refactoring/rearchitecting

This is the once in a few years (hopefully) work that will more likely be required on a long-term project. Platforms move on, best practice updates, new APIs are added, devices change, user expectation increases. Maybe these have moved on to such a degree that it is no longer viable to carry on developing on the current codebase. It is likely that to address this it is going to require a going-back-to-the-drawing-board type refactor, revisiting the approach, the architecture, maybe even the language. Massive projects have come unstuck (or got stuck) at this point and simply not been able to move forward and update.

These type of decisions are beyond the scope of this post, but needless-to-say, would require considerable conversation between the client and the development team. For a continually evolving project, refactoring on this scale should usually be completed on a reasonably regular basis, in order that technical debt isn’t accrued so much that it becomes impossible to do the work required. The alternative often relies on a build-up of work-arounds and temporary hacks to support the continual project additions, adaptations and changes.

Small, ongoing refactoring

It is likely that whilst completing normal development tasks, small areas of refactoring will emerge that are broadly in line with the scale of the current development tasks. When we’re deciding whether to complete refactoring in this case, it is likely we (as an agency) are making the decision on behalf of the client. It is probable that an individual developer will make the decision, maybe after gathering input from our own team.

Using empathy in this situation will help us to make a good choice for our client. We should simply ask ourselves ‘Does it benefit the client in the short- or medium-term?’. We should never make the decision to refactor based on anything that only benefits us, eg: “It makes our life easier” or “It’s just how we do things now”. These may be additional factors, but ultimately it has to come back to client benefit. We exist to serve our clients needs and not our own agendas.

The reason we’re suggesting to look at the short- or medium-term benefit and not long-term, is that as an external partner we cannot be sure what involvement we’ll have in the long-term. We work with our clients extremely long-term but we don’t want to presume this, nor do we know the client’s long-term plans for the project. If there is only a long-term benefit to the refactoring then this work can only be decided upon with the specific agreement of the client.

---

---

Growing empathy in a software team

Given the importance of empathy with team dynamics and specifically within software teams, it is important as agency leaders we actively look at how we can grow empathy within our software teams. We’re fortunate that the development team here at Brightec is made up of mature, articulate and social individuals, all of which I’m very happy to put in a room with all our clients (with no supervision). Nevertheless, it is important that we encourage our team to have empathy for our clients, to understand what they are feeling.

We will explore this in a future post, but a simple way to build empathy in this context is to ensure regular face-to-face time between our individual team members and the client team. Meeting together and where possible working together, go a long way to build trust and understanding between individuals leading to empathy.

Once empathy is established and a deep working relationship is formed, the conversation around ‘When to refactor’ is framed correctly and a better decision can be reached by the individuals involved.