Return to Answer

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not rewriting code) and it's the context.

We, developers, more often than not have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, no matter what it takes. I'm a problem solver. To some extent... But I'm supposed to be something more than a braindead lemming chopping and digging.

After many years of rushing at doing the first, I learnt that I have to be aware of the project's stage. Sometimes the decision to fix a bug that requires a code refactor is not on me but on the PM.

PMs hold accountability for many decisions, sometimes even if a bug should be fixed or not and the way to do it. We have to know when we can do something or when we should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, we won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. We are not allowed to make that decision unilaterally if we can't measure accurately the impact on the planification. Even if we have a large plan of automated tests. What it's expected from us then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the project's stage. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not) rewriting code and it's context.

We, developers, more often than not have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, no matter what it takes. I'm a problem solver. To some extent, because I'm supposed to be something more than a braindead lemming chopping and digging.

After many years of rushing at doing the first, I learnt that I have to be aware of the project's stage. Sometimes the decision to fix a bug that requires a code refactor is not on me but on the PM.

PMs hold accountability for many decisions, sometimes even if a bug should be fixed or not and the way to do it. We have to know when we can do something or when we should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, we won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. We are not allowed to make that decision unilaterally if we can't measure accurately the impact on the planification. Even if we have a large plan of automated tests. What it's expected from us then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the project's stage. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not rewriting code) and it's the context.

We, developers, more often than not have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, no matter what it takes. I'm a problem solver. To some extent... But I'm supposed to be something more than braindead lemmings chopping and digging.

After many years of rushing at doing the first, I learnt that I have to be aware of the project's stage. Sometimes the decision to fix a bug that requires a code refactor is not on me but on the PM.

PMs hold accountability for many decisions, sometimes even if a bug should be fixed or not and the way to do it. We have to know when we can do something or when we should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, we won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. We are not allowed to make that decision unilaterally if we can't measure accurately the impact on the planification. Even if we have a large plan of automated tests. What it's expected from us then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the project's stage. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not rewriting code) and it's the context.

We, developers, more often than not have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, no matter what it takes. I'm a problem solver. To some extent... But I'm supposed to be something more than a braindead lemming chopping and digging.

After many years of rushing at doing the first, I learnt that I have to be aware of the project's stage. Sometimes the decision to fix a bug that requires a code refactor is not on me but on the PM.

PMs hold accountability for many decisions, sometimes even if a bug should be fixed or not and the way to do it. We have to know when we can do something or when we should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, we won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. We are not allowed to make that decision unilaterally if we can't measure accurately the impact on the planification. Even if we have a large plan of automated tests. What it's expected from us then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the project's stage. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not rewriting code), and it's the context.

We, developers, more often than not, have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, not matter what it takes. I'm (we're) a problem solver. To some extent... But we are something more than braindead lemmings chopping and digging. Aren't we?

After many years of rushing at doing the first, I learnt that I have to be aware of the moment we are in. Sometimes the decision to solve a problem that requires a code refactor is not on me (or you) but on the PM. It holds the accountability of many decisions, sometimes even if a bug should be fixed or not and the way to approach the solution. You have to know when you have the OK to take it forward or when you should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, you won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. You are not allowed to make that decision unilaterally if you can't measure accurately the impact of the changes and assure that there won't be any impact on the planification. Even if you have a large plan of automated tests. What it's expected from you then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy having only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the stage of the project. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.

In addition to @ThomasOwen's answer, which I agree with, I miss something more when it comes to considering (or not rewriting code) and it's the context.

We, developers, more often than not have very little perspective of the whole. Intended or not, we barely know the overall picture and it's especially true when we speak about the planning.

When I find myself in a similar situation, my first impulse is always to fix the problem, no matter what it takes. I'm a problem solver. To some extent... But I'm supposed to be something more than braindead lemmings chopping and digging.

After many years of rushing at doing the first, I learnt that I have to be aware of the project's stage. Sometimes the decision to fix a bug that requires a code refactor is not on me but on the PM.

PMs hold accountability for many decisions, sometimes even if a bug should be fixed or not and the way to do it. We have to know when we can do something or when we should ask first. Here, we call that "raising the hand".

Most of the time, during the coding phase, we won't need the OK to keep going. It's expected to find and solve bugs as they appear. But 1 week before the release... Sorry, but no. We are not allowed to make that decision unilaterally if we can't measure accurately the impact on the planification. Even if we have a large plan of automated tests. What it's expected from us then is to reach the PM and explain the situation, give solutions (as PM I wouldn't buy only 1) and the pros and cons of each of them, so the PM (and the rest of the stakeholders) can make the best decision possible.

So, besides testing, be aware of the project's stage. Understand the issue and its cause so you can size the solution accordingly and, if the solution is not that simple, then do nothing without the due approval. You should not reduce things to a simple method 1 or 2 and nothing else. It's tempting to oversimplify things, but going with methods 1, 2 or 3 is contextual too.