• Who’s responsible for refactoring?

    A topic that frequently comes up when talking to developers is the topic of refactoring. Refactoring is often linked to technical debt. Technical debt is shortcuts that we take consciously or subconsciously (god forbid). Refactoring is one of the most popular technique to address technical debt but not the only way to address it. The most popular definition of refactoring is that we make changes to the internal structure of the application to make it easier to understand without changing the behavior. If we change the public API that a client calls then we are redesigning and not just refactoring.

    If we come to the conclusion that we need to refactor the question becomes who’s responsible for it? Since it’s a development task, this usually means that the developer’s on the team is responsible┬áto address it for obvious reasons. The more interesting question is, should the developers take it on themselves or should the issue be raised to the whole team and even to the product owner?

    It depends on the context. If we are working on a user story that touches code that we already know or realize as we are implementing the user story that it needs to be refactored and it won’t increase the scope of the story then we of course should refactor it. Remember to include the tester’s in this conversation since this may need to be tested more thoroughly now than before the team started working on the user story.

    There are cases when we run across an area that needs to be refactored but it may either be very complicated/time consuming or we may even need to re-design this part of the application. This is a case when the product owner should be aware and plan for it. How can we tell the product owner that we aren’t doing a good job since we have to refactor? It comes down to trust, a good product owner that trusts the team will trust the team if you explain that to meet deadlines for important features some shortcuts had to be taken but the velocity over time will go down and it will be more likely that we will find defects in the area if we don’t address this soon.

    If the product owner thinks that the team isn’t being upfront and just want to re-design things for the fun of it, the question becomes why is the product owner lacking trust in the team? Are we lacking trust for a good reason? Are we lacking trust because we have silo’s and the product owner isn’t engaged with the team as frequently as the team needs? These trust problems can be difficult to resolve but can be as simple as take your product owner to lunch and get to know him/her better, understand what other responsibilities outside of this project that they have. The better social relationship we have to people, the┬ámore likely it is that we build trust.

    Categories: refactor, technical debt

    Tags: ,

    Leave a Reply

    Your email address will not be published. Required fields are marked *