Hacker News new | ask | show | jobs
by ok123456 1571 days ago
His "solutions" is to work in "pockets of the industry" that don't have "bloat". (Among one of them is use more cloud services. Which makes me wonder if he's seen some of the engineering disasters people are churning out. This makes me want to just summarily dismiss the whole piece.)

The real solution is to systematically address technical debt as part of your development process. Did that feature that someone swore up and down would be your money maker three years ago not pan out? Delete. Is that abstraction leaky and not that useful? Delete. Are there code paths that never get used and are more or less untested? Delete or assert they never happen.
2 comments
bombcar 1571 days ago
My suspicion is that any "cloud service" that isn't some proof-of-concept one-off is also filled to the brim with bloat, you just don't see it as a customer.

"Delete" is the solution, but that is a tool they don't want to use, because every feature somewhere is used by some paying customer, who will complain loudly - and may even move to a competitor. Often the pain of updating and the pain of migrating are similar.

link
yjftsjthsd-h 1571 days ago
> My suspicion is that any "cloud service" that isn't some proof-of-concept one-off is also filled to the brim with bloat, you just don't see it as a customer.

Hey, encapsulation is a decent mitigation to complexity issues.

link
ok123456 1571 days ago
uh yeah until you need to modify it, then it becomes another complexity issue. Or in the case of 'microservices', now you have to solve a distributed systems problem.
link
yjftsjthsd-h 1571 days ago
No, you're still better off having clearly defined boundaries. I will grant that multiple systems can have emergent effects that are more painful to debug, but to the degree that things can actually be made independent I think it helps.
link
oriolid 1571 days ago
For that real solution you need to have a manager who approves spending time on removing unused cruft. Otherwise you'll end up smuggling refactoring inside other tasks, which is terrible for quality control.
link
akitzmiller 1571 days ago
I think this is really the crux of the matter. More generally, STABLE management that drives software quality. Even if you're lucky enough to be part of a team that starts of with good management, reorgs, mergers, and turnover are just way too frequent to provide the year-over-year improvements needed for really good, efficient code.
link