Projects are punctuated with changes all the time. On programming projects, these changes are of all shapes and sizes. Small changes are usually unnoticed, but bigger changes usually generate more stress and cleavage.

When to ask?

When a change is not controversial and that it is small enough, a brief discussion on a pull request is all it takes to find the right solution in a group.

It is usually a good time to ask when

  • there is a huge impact
  • there are multiple solutions and a discussion is necessary
  • it is controversial

In each of these situations, it is always best to inform the group that a change has to be made and a collegial solution has to be found.

And of course, it is always best to ask upfront for these types of changes.

cost of change

Why change?

Probably the first legitimate question being asked is *why change *? After all, it works as is, and change can lead to fear.


On a time-based evaluation, the current solution takes no time whereas new solution takes an unknown amount of time but this amount if greater than 0 and this is enough to decline the new solution.

I'm not saying that the time necessary to achieve the new solution is not to be taken into account, it really should.

But sometimes, the current solution is no longer viable. It might be due to a performance issue, a regulatory issue or that it will no longer be supported or even that it is not compatible with new evolutions. Maybe it is also because the current solution makes every new evolution painful. In this sense, the current solution might be suffering from technical debt. There might be plenty of reasons to change, but it has to be justified.

Compare objectively

Probably the best thing to do is to compare previous and new solutions together without considering the cost of each. Only comparing objective aspects like technical debt, performance, ease of administration, right tool for the job and such.

If the previous solution is better then there is no argument to be made. But if the new solution is better, there has to be a solid argument to why it is not scheduled. Time can rarely be an issue if the new solution decreases technical debt, reduces maintenance and future evolutions.

Banish bikeshedding


As Yoda said, anger and hate are not far from these kinds of debates. This is why the fundamental rule for choosing a solution is to let ego aside in order to stay away from bikeshedding.

Plan accordingly

technical debt
Technical debt is often perceived as something invented by developers to have a pretty architecture and nice looking code, but there is more to it and it has a real impact on delays, bugs, performance, turnover, general comprehension, training, and motivation. There should always be room for refactoring when necessary.