Bug or feature?

• Refactoring

Anyone who has ever seriously attempted refactoring has probably encountered this kind of code:

class Game {
  // tout plein de choses qui vous font saigner les yeux

  private didPlayerWin(): boolean {
    return this.points[this.currentPlayer] != 6;
  }
}

It doesn’t take a genius to see that there’s a problem: since players start the game with 0 points, every player is a winner even before the game has begun 😳

A brief moment of hesitation, though: could this be a “third-type” feature? In other words: bug or feature?

Here, the rest of the code would confirm your intuition that this is a glaring error. But in many cases, the question remains unresolved. Perhaps you’ll come across some functional documentation, and if so, let’s hope it’s up to date and doesn’t contradict the code.

The best thing to do would be to ask someone, a developer or a product manager, but the thing is, all those folks have long since moved on to new horizons, leaving you alone with your questions 🥲 The bad news is that there’s no ready-made solution: you’ll have to tackle this armed with your common sense and a solid understanding of the business.

What should you do next if the bug is confirmed? This question may seem surprising, but… should you fix it? After all, if the bug has been around for years, it’s a safe bet that the outside world has already implemented its own workarounds to “deal with it.”

Non-computer-science example: Imagine your faucet is installed backwards. When you turn on the cold water, hot water comes out, and vice versa. You’ve certainly burned yourself once, but you didn’t feel like taking the whole thing apart, so you adapted: to get cold water, you ask for hot water, and vice versa. It’s easy, after all: you just have to know how.

Of course, if you invite me over and I fix the problem without telling you, you’ll probably let out a loud scream the next time you wash your hands.

In other words, if you fix the bug, all third-party systems that use your service will have to remove the workarounds they’d put in place to deal with it. So you need to be able to notify them and coordinate everyone involved. In some cases, this is feasible (e.g., an API used by a single front-end); in others, it’s much more complicated and perhaps unfeasible (e.g., numerous institutional clients who must be contacted individually for a legacy system that’s doomed in the long term but needs to be updated in the short term).

So what should you do? In such a situation, you might consider fixing the bug and immediately reintroducing it through a subtle overlay. This practice, though paradoxical, allows you to isolate the malfunctioning code and enables the rest of the codebase to evolve freely while ensuring its functional consistency at all times.

If you can’t resolve the problem, you’ll have to settle for containing it.