Return to Answer

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why people are suggesting things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

Fundamentally, with option 1, you are overturning a convention, "color tags don't have a hash", with another one "yes they do". Spreading a design decision like this around makes me sad but I'll admit there are times when you can't avoid it. The pain you're feeling is about how widely it has already been spread.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why people are suggesting things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

Fundamentally, with option 1, you are overturning a convention, "color tags don't have a hash", with another one "yes they do". Spreading a design decision like this around makes me sad but I'll admit there are times when you can't avoid it. The pain you're feeling is about how widely it has already been spread.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.

Of course option 3 (create a separate function) doesn't fix the "hard-to-detect visual bug". If you can't fit fixing that in your sprint then toss it into the backlog and get it prioritized. The most important thing to do here is explain the bug well. The work to do here is hard. The bug is subtle. So people will resist fixing it. Find a way to make the problem glaringly obvious. Write a test if you have to. Don't let them sweep it under the rug without a fight.

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why you're saying things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

Fundamentally, with option 1, you are overturning a convention, "color tags don't have a hash", with another one "yes they do". Spreading a design decision like this around makes me sad but I'll admit there are times when you can't avoid it. The pain you're feeling is about how widely it has already been spread.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why people are suggesting things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

Fundamentally, with option 1, you are overturning a convention, "color tags don't have a hash", with another one "yes they do". Spreading a design decision like this around makes me sad but I'll admit there are times when you can't avoid it. The pain you're feeling is about how widely it has already been spread.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why you're saying things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.

I suspect this is a fight over a name.

Option 3 (create a separate function) is absolutely the best. Provided you can think of a good name for the new function. But I suspect you can't. That's why you're saying things like normalizeCssColorWithHash. Yuck. I think you'd really prefer that only one function was named normalizeCssColor and it just worked without having to think about stupid hash details. Which is why you're thinking about option 1 (update existing).

A truly good name won't focus on the steps taken inside the function. It will focus on the expectations of the code outside it. Give me a name that explains why you would call it. Not what it does. But such a name isn't always available.

Without a good name, option 1 is worth serious consideration. Nothing messes up a code base worse than bad names. However, option 1 is a lot of work. It explodes the scope of your ticket. It makes option 3 tempting. However, option 3 comes with the risk of never following up and leaving you stuck with a bad name.

Fundamentally, with option 1, you are overturning a convention, "color tags don't have a hash", with another one "yes they do". Spreading a design decision like this around makes me sad but I'll admit there are times when you can't avoid it. The pain you're feeling is about how widely it has already been spread.

When faced with decisions like this I take the cowards way out. I do the quick and expedient thing as fast as I can (option 3) then pretend I didn't and see how far I get with the serious solution (option 1). If I can get option 1 done before the deadline (whatever your sprint is) no one ever knows I had option 3 done already.

If I doubt if can hide the dilemma like that I stop mid sprint and ask the team. Who usually go with the conservative solution (option 3) unless the problem (the name) is really bad.