Did anyone else feel turned off by the AI-written writing style of this? (Grammarly claims it’s 13% AI generated, although I’m not sure how accurate that is.)
It's a 30-second read, so it didn't particularly bother me.
I've done consulting in esoteric products, so the content is accurate and a useful cautionary tale.
Imho, the skill gap is the original sin. If the team inheriting ownership is seriously underskilled, no amount of knowledge transfer is going to fix that -- so stick to whatever is dirt simple and most obvious in language du project.
I skimmed it; I didn’t think it was ai necessarily, but in between topic sentences it was boring filler no matter how it was written.
Even at a high level though, it’s poorly reasoned. If quality code is not maintainable, what are your criteria for quality exactly? It’s basically an ad for consulting services targeted at people without strong critical reasoning skills.
"I think this is AI" is the least interesting, lowest-signal comment one can make here on HN, beating out perennial contenders "I hate their scroll bar", "this site hijacks my back button", and "why does this site require JavaScript?"
If you can actually make an AI detector that works, do that and print money for yourself. Otherwise accept that all "AI detectors" have massive false positive rates, your intuition included.
If visitors like what they see on the page, they will up vote it. If they don't, they won't. That's how HN works.
I mean I argued with another guy for about an hour but they had a thing against comments, it should be in the git logs. Which I understand but I sort of feel it should be in both places because some people are lazy.
> In the best case, they lead to accumulating inefficiencies (technical debt) as engineers work around them
If that's what technical debt ever amounted to, then the average software developer is stupid, because he doesn't know how to innovate and improve within the meta-system he's functioning in. It's not hard to restructure things when inefficiency becomes a problem. Just do it.
Instead of lionizing technical debt as some sort of boogeyman demon around the Internet forums water coolers.
This is true even for non-consultants. If you're the only person who understands The Thing you're in for a world of hurt because whenever it breaks it's your problem. I've been at companies where I rearchitected a piece of software and unfucked some key business process, but it made things worse because the number of engineers who understood it went down. And I'm not talking vanity "paying down tech debt" rearchitecting, I'm talking "people get paged because the product doesn't work" went from 33% of deploys to ~0%.
Great article, I have I seen this situation too many times to count. It isn't just consultants that generate haunted graveyards. Any person will skills more advanced than their peers will do so. To make matters worse it isn't just the peers you have right now but the peers you will have in the future who you don't currently know and can't predict their skill level.
While the solutions you list can help, it will not solve the haunted graveyard problem, just ask all of the companies with Cobol programs in production.
13 comments
[ 5.9 ms ] story [ 47.0 ms ] threadI've done consulting in esoteric products, so the content is accurate and a useful cautionary tale.
Imho, the skill gap is the original sin. If the team inheriting ownership is seriously underskilled, no amount of knowledge transfer is going to fix that -- so stick to whatever is dirt simple and most obvious in language du project.
Even at a high level though, it’s poorly reasoned. If quality code is not maintainable, what are your criteria for quality exactly? It’s basically an ad for consulting services targeted at people without strong critical reasoning skills.
If you can actually make an AI detector that works, do that and print money for yourself. Otherwise accept that all "AI detectors" have massive false positive rates, your intuition included.
If visitors like what they see on the page, they will up vote it. If they don't, they won't. That's how HN works.
// Ugly hack. To fix later {inserts reasons and breadcrumbs here}
Beats naked magic numbers/logic any day of the week.
So probably it's been "fixed" and caused stuff to break since then.
If that's what technical debt ever amounted to, then the average software developer is stupid, because he doesn't know how to innovate and improve within the meta-system he's functioning in. It's not hard to restructure things when inefficiency becomes a problem. Just do it.
Instead of lionizing technical debt as some sort of boogeyman demon around the Internet forums water coolers.
While the solutions you list can help, it will not solve the haunted graveyard problem, just ask all of the companies with Cobol programs in production.