I have this impulse to constantly experiment with everything too. And I think it's healthy for your brain to always be learning new ways and testing your preconceived notions of how you do things. A lot of times it leads to incremental advances, either in the next iteration of my existing code or the way I approach my next project.
But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.
> But a lot of it, I can admit, boils down to sheep shaving.
AKA Yak shaving[0], which I am... unashamedly fond of doing
>> There are yaks to shave all over the stack, and I go where the yaks are.
(quote is from my github readme)
> When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.
I definitely agree that selling this to a client when you've told them you'll do the minimum to update the codebase is immoral, but if there is value in updating, then you should expose them that value.
For example -- moving a client to AWS might not make sense, but if they're maintaining on-prem infra and paying tons of money for an application that would actually cost less as a single ECS service (or App Runner, these days)... Then maybe you should upgrade their stack a little bit.
In the end it's your job as a consultant or an employee (if you're high level enough) to introduce change that will make the company better, if you see an opportunity.
Tech stacks crumble underneath their own weight, and if they're bad enough, become business risks. If it's humming along, easy to maintain, and isn't riddled with security holes, then great!
My idea of a major overhaul for a client is upgrading from Mysql 5.7 to 8 with no downtime and then slowly, over a year, finding queries that could be sped up with lateral subqueries or window functions. That's about the pace, and it's effective at keeping resource use in check. The wilder things I experiment with on the side are once in awhile actually useful for a new app or service...
I basically agree with you, if the cost of building the code will be easily outweighed by the savings to the client and I also think the platform will hold them for the next 10 years, I'll pitch it [e.g. I've moved many early clients from my servers over to AWS services when it made sense, and still maintain them]. But it's easy to see too how if I were trying to constantly drum up more work, it would be seductive to pitch them on new hyped up technologies they don't need, just to remain relevant and keep the checks flowing. I think that's the animating force behind all of this platform churn, not excited developers who just want to sheep or yak-shave (thanks. I always forget which ruminant I'm shaving ;)
But a lot of it, I can admit, boils down to sheep shaving. When you start figuring out how you'd implement codebase 2009 in stack 2023, and then actually doing it, that's golf. It's all good, it's educational, but it's downright immoral to sell that to a client and drag them through it.