When 'Best Practices' Bite You

I know it's a cliché, but there's no silver bullet. Is refactoring always worth it? No. Is Test-Driven Development always beneficial? Of course not. Should you always add test scenarios to cover every known gap? No. Should automated tests be your goal in every project? Again, no.

Don't get me wrong, I'm far from advocating against these solutions. In fact, I recommend quite the opposite; you should have a compelling reason not to use them. And trust me, your project is likely not as unique as you think. In most cases, developers' arguments against these practices are excuses, not justifications.

However, we should give each decision a moment of reflection and assess whether the benefits truly outweigh the costs. Even your favorite approaches can increase costs and slow down implementation at best, or render it unprofitable at worst.

Here are a few questions you should ask yourself before committing to a decision, to better understand its potential cost:

• Is this the right time? Imagine you plan to extract part of the code and convert it into a dedicated service. Unfortunately, your tests are far from perfect; you know you can't rely on them to guarantee functionality after the move. The ideal solution? Cover it with tests, then proceed. Yet, even framing it as an option can feel overwhelming. What else can you do? You could extract and deploy, then use a Parallel Run Pattern to validate if the new service behaves like the old code.
  
  
• Is a different approach truly better? Have you ever been tempted to improve the code architecture? You might be convinced you've found the perfect solution, certainly better than the ubiquitous coupling. Almost ubiquitous, because you noticed there's also an attempt at layered architecture. Of course, this is inferior to your envisioned improvements. But are you sure? And even if it is, is the difference worth introducing yet another architectural pattern? Or do both approaches address the main challenges and obstacles and the difference is negligible?
  
  
• Is the risk really that significant? A years ago, my team, with our tech lead, spent a week analyzing, finding the root cause, and fixing a production bug. After the post-mortem, our project manager asked if there were tests we could introduce to prevent such issues. The answer was yes. And you know what? We decided against the tests because the risk of recurrence was low, and the cost of creating test suite and maintenaning it was high. Plus, during analysis, we discovered a quick validation method for similar issues and a straightforward solution.

As I stated at the beginning, these questions shouldn't justify maintaining a slowly degrading legacy system. Quite the opposite. They can help you prioritize improvements and mitigate risks. By answering them, you can focus on the most impactful and beneficial actions.