Introductory bullshit detection for non-technical managers

Re:Introductory bullshit detection for non-technical managers by eight_ender on Monday July 10, 2017 @01:11AM (#14733528)

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.

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by omginternets on Monday July 10, 2017 @10:32AM (#14736241)

>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".

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by ljw1001 on Tuesday July 11, 2017 @07:51AM (#14743341)

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.

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by omginternets on Tuesday July 11, 2017 @09:04AM (#14743797)

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.

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by xsmasher on Tuesday July 11, 2017 @04:00PM (#14747511)

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.

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by megablast on Monday July 10, 2017 @05:12AM (#14734389)

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?

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by Nadya on Monday July 10, 2017 @10:46AM (#14736388)

> 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.

[ Parent | on HN ]

Re:Introductory bullshit detection for non-technical managers by samdg on Monday July 10, 2017 @11:14AM (#14736627)

Because you needed a "generic" version of it, but your manager read this article and told you not to do it...

[ Parent | on HN ]