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.

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

Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.

There's a checklist in the "Value" section of the article than can help sort out what value (if any) the refactor has.

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.

Just over a year ago the code base was handed over to a technical team (there used to just be one coder (never the same coder as they all seemed to hate the product and move on, now we know why)) to review, and fix to make it more scalable. Well to put it lightly it is a complete cluster fuck that has seen a couple people resign and it is not worth trying to fix.

Now the burden has become trying to convince the business people that drastic steps need to be taken (ie full re-write). They don't seem to want to even entertain the idea, so not sure what is actually going to happen.

However, I think it's a completely valid article if you've ever experienced the interactions between an unproductive programmer and their non-technical manager. I've witnessed this dance every week for the past 3 years. The programmer in this case has used every one of those phrases except "platform independent".

Acton is the engine lead over at Insomniac Games, and has been shipping that sort of work (routinely refactored/updated) for years. He's an exceptionally pragmatic tech lead.

Generalizing this to all of software development is still a bit presumptuous though.

When you hear “refactoring” it’s a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of. I recommend reading Paying Down Your Technical Debt to get a basic understanding of the concept.

However, it can also be just an excuse to change things to some conception of “better” for no real benefit. Whatever better means to that programmer today, you can be confident that they’ll think it’s shit in a couple of years as they gain more experience and skill. That’s totally fine, but you can’t afford to get caught up in a loop of always retrofitting everything to “better” every time the definition of better changes. Unless you’re Google, in which case you keep doing that until some other team solves the actual problem and your project gets deprecated.

I don't doubt that the author is good at this job, but I think we're seeing an 'unconscious competence' issue. If I say "Java is platform-independent while C++ isn't", the author probably knows enough to think "well, that's a factual statement, not a red flag". But the person reading the checklist he wrote probably doesn't.

Honestly, I got some value out of this article as a list of things to ask myself. But it seems to be aimed at exactly the people who won't be able to interpret it effectively, and will misapply the hard-and-fast rules here.

It will always be possible to accuse an article or even a book of being light on details. It is after all some pointers and not a scheme to make a non-technical manager technical. Learning anything takes more than reading at surface level, particularly of a clearly introductory article. The principle of charity goes a long way to smoothing out the inner pedant.

Certainly true, and I do think people skipped the section on refactoring. But I guess my real complaint here is that the article itself seems to advocate against the principle of charity!

Asserting that generic versions and frameworks are inherently 'red flags' that someone doesn't know how to do their job doesn't seem like an inducement to more reading, it seems like a misleading absolute. I got that feeling throughout the whole piece, for instance with the implication that memory limits are key in all tasks.

It was either very domain-specific advice (I know the author came out of game design, which fits his list better than general software), or vastly overstated advice.

I don't think they're being introduced as red flags to say "call bullshit on this and don't do it" but to be aware in the following cost-benefit analysis.