4 ms·

Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the

Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the bar on quality. Sometimes it's about challenging assumptions by the developer that were completely valid when they wrote the original code that aren't now through hindsight, technology changes, etc. It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.

megablast 9y ago
And a non-tech person will have great difficulty understanding that, or why? Why didn't you just write it correctly in the first place?
- Nadya 9y ago
  > Why didn't you just write it correctly in the first place? For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support) That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
- samdg 9y ago
  Because you needed a "generic" version of it, but your manager read this article and told you not to do it...
omginternets 9y ago
>Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".
- eddigo 9y ago
  Also, if you hear the term "refactoring" too much and the system being built still does not work, then that's probably a good indicator of bullshit. Engineers (and managers) need to be taught to resist the urge to refactor before the system solves the problem. Once you've solved the problem, you've connected things end-to-end, and only then will you know what refactoring makes sense. Ugly code that works > pretty code that does not work
- ljw1001 9y ago
  Having been both a manager and engineer for a number of years in a number of organizations, I can say with some confidence that an excess of refactoring is NOT the problem.
  - omginternets 9y ago
    Having worked as a contractor for many years, I can say with absolute certainty that actual excess refactoring is not a problem, but that claims of refactoring very much are. Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.
xsmasher 9y ago
Refactoring without a clear and stated purpose is bad. Refactoring WITH a clear and stated purpose may also be bad, if the purpose is bad; "Support some use cases we don't care about," etc. There's a checklist in the "Value" section of the article than can help sort out what value (if any) the refactor has.

megablast 9y ago

And a non-tech person will have great difficulty understanding that, or why? Why didn't you just write it correctly in the first place?

Nadya 9y ago
> Why didn't you just write it correctly in the first place? For the same reason Bluray replaced DVD replaced VHS. "The better solution didn't even exist at the time" (new browser features) often coupled with the equivalent of "Now everyone has a Bluray player so we can start using Bluray features going forward." (ubiquitous browser support) That tends to get understood by my management. Compare it to something they are familiar with - and anyone over the age of 25 will be familiar with the BR/DVD/VHS comparisons.
samdg 9y ago
Because you needed a "generic" version of it, but your manager read this article and told you not to do it...

omginternets 9y ago

>Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".

eddigo 9y ago
Also, if you hear the term "refactoring" too much and the system being built still does not work, then that's probably a good indicator of bullshit. Engineers (and managers) need to be taught to resist the urge to refactor before the system solves the problem. Once you've solved the problem, you've connected things end-to-end, and only then will you know what refactoring makes sense. Ugly code that works > pretty code that does not work
ljw1001 9y ago
Having been both a manager and engineer for a number of years in a number of organizations, I can say with some confidence that an excess of refactoring is NOT the problem.
- omginternets 9y ago
  Having worked as a contractor for many years, I can say with absolute certainty that actual excess refactoring is not a problem, but that claims of refactoring very much are. Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.

xsmasher 9y ago

Refactoring without a clear and stated purpose is bad. Refactoring WITH a clear and stated purpose may also be bad, if the purpose is bad; "Support some use cases we don't care about," etc. There's a checklist in the "Value" section of the article than can help sort out what value (if any) the refactor has.