Fixing Things Later in Software Engineering

3 min read

In the world of software development, staying focused is paramount, especially when you’re working within the Agile framework. Think about it like this: You’re on a road trip, and Agile is your GPS, guiding you to your destination (the project goal) within a fixed amount of time (your sprint). It’s all about hitting those milestones with a clear plan, something that’s usually estimated and agreed upon by your team in advance.

But here’s the thing, and I bet every developer can relate: As you dive into your tasks, you often stumble upon unexpected detours – non optimal code, smells, ideas for refactoring, code reorganization, or even glaring issues that demand attention. In a team laser-focused on the goal, a common refrain you’ll hear is,

“We’ll fix this later.”

And honestly, that’s not a bad approach, provided you follow a few key principles.

Fixing Something Later Should be a Conscious Decision

Remember, choosing to fix something later should be a deliberate choice, not the default reaction. Each finding during development is like a fork in the road – some paths can wait, but others, like urgent security issues, need immediate attention. When in doubt, it’s like asking for directions; consult your team to make a joint decision.

Document your findings

Imagine your findings as crucial pieces of a puzzle. You can’t afford to lose any of them. It’s essential to document these insights with the utmost care. Utilize backlogs and scrum tools as your digital notebooks. This discipline in recording every detail isn’t just helpful; it’s a cornerstone of successful project management. The finding should also immediatelly be documented - backlogs and various backlog or scrum tools are perfect for it. Use them, it is a matter of discipline.

A Real-World Story

Let me share a story from my own experience. Picture this: A high-stakes project with a non-negotiable deadline smack in the middle of summer, when half the team is sipping cocktails on a beach somewhere. It was a classic “do or die” situation. Deliver a mediocre product on time or lose the project altogether. Our solution? Focus on delivering all the features while maintaining a separate backlog for everything we did “quick and dirty” and all the other findings we had. We managed to meet the deadline, and the client was over the moon. At the end we agreed upon dedicating the next two sprints to process our “fix-it-later” backlog.

Later is not never

Think of your “fix-it-later” backlog more as a to-do list, not a storage closet where all problems go to be forgotten. It should be a living, breathing part of your main backlog, ideally tackled bit by bit in your planning or as in our example above - processed in dedicated sprints.

Key take aways

It’s about maintaining a laser focus on your immediate goals while skillfully managing the unexpected detours that inevitably arise. Ultimately, the true skill in software engineering lies in navigating the journey with adaptability and foresight, ensuring each step contributes meaningfully to a well-crafted final product.