Refactoring to maintainability

Tradition

The Setup

Did you know that the Royal Assent that is given to UK parliamentary bills is in French? That it is, all the UK laws are finally approved in French. This is a tradition back to when the Normands took power in England after the death of Edward the Confessor.

Why not change it to English? “Is the tradition!!!” They will say.

And how many times I have heard that before when questioning a specific process, tool, …: That is how we have always done it.

Historical Context

I have mentioned before that context is important. Every thing you say and do is based on a specific context. When that context changes, what you say or do could/needs to change. If the rationale for a specific action disappears, so should the action. Maintaining rules and actions just because of inertia, leads to non-efficient outcomes, in the best of cases, or bad outcomes, in the worst cases.

Another idea that I keep coming back to is the extreme attrition rate on companies. That attrition rate means the lost of business/technical knowledge and the loss of historical context to the decisions taken. You can see issues constantly on clients where you ask why a thing is being done a specific way, and the answer is a shrug, because the information was lost when the people responsible left.

This is why I am a fan of Architectural Decision Records(ADRs). They record the historical context. They allow to come back in the future and investigate. It makes me happy when a company I go to work with have ADRs, because is so much easier to gain the understanding. Of course, not everything goes into an ADR, company politics don’t tend to be recorded, for example, but through the gleaning of them there is hidden context that can be surmised.

As a consultant, I believe that knowing and understanding that historical context is important to understand the current situation in which a company/client is set. This not only helps in making the case for changes, but also in knowing what not to propose if something was already investigated and discarded in the past and the context for it hasn’t changed.

Retrospectives and Postmortems

No decision should be decided once and set in stone for ever. An important step is to actually evaluate the decision with knowledge of the effects. Retrospectives and Postmortems should be part of the toolbox of any company, and should be used liberally to revise decisions, understand their consequences and evaluate when the context for them has changed. That of course means that we need to be able to evaluate decisions taken. Some are easy to evaluate, some more complicated. But something being complicated doesn’t mean you shouldn’t try it.

As an interesting aside, I tend to use the term retrospective for the event that occurs regularly while a project is being worked on (weekly, bi-weekly), and postmortem when the project is done.

Marginal changes

One of the issues/thinking that I have encountered was the duo of no point on doing these small changes and we don't have time to do the big changes (well, or any change at all). The result is, basically, no change ever happens.

But changes of any size do have an effect, and sometimes even marginal changes have a cumulative effect that massively moves the needle of effect/efficiency/usefulness … Matthew Syed has a talk in which he does refer to these marginal changes, first from the point of view of healthcare and then from the point of view of the Sky Team cycling team.

Every change, small or large, could and will bring you closer to your objective(s).

Changes!!!!!!!

I am not advocating to keep doing changes all the time. That leads to change for the sake of change and is very ineffective. It could also can bring change fatigue. But I advocate for the discrete evaluation of context and metrics to understand if decisions need to be changed. Whenever you want to exert a change, it needs to have an objective in mind. And, ideally, a raft of changes all have a common objective. Multiple changes in different directions could have a negative effect, confusing people.

The End

I dislike keeping systems just because is the tradition, because it was always done this way, or because a decision was taken at the dawn of time. If context changes, so those systems and decisions.