4 ms·

Also it is almost never for "funsies," it is instead usually the "wrong solution" to a very real problem. The current system has bad performance, or doesn't sup

Also it is almost never for "funsies," it is instead usually the "wrong solution" to a very real problem. The current system has bad performance, or doesn't support some new use case that is a major company initiative or whatever. But instead of fixing/augmenting the existing system the (probably multiple accumulated pain points by now) are used to justify an overly complex change. In fact the change probably becomes known internally at the company as some silver bullet that will fix all woes further reinforcing the drive to do it. Even the best developers get ignored if they try to justify pure-tech-debt fixes. So they learn to include fixing tech-debt as part of a fixing a problem that has some _direct_ business relevance if addressed. This gets clearly observed and taught to the all tiers of developers further obscuring the rationale for architectural changes from more senior management.

BigJono 6y ago
Yeah the key thing here is it's just so easy to spin anything as the solution to some problem the company has, and there's always problems around. "for funsies" probably isn't that far off. Because the process is more like someone gets interested in something at some point. Then at that point +~1-6 months someone raises a problem and some senior dev gets stuck on the idea that the awesome thing they read about can solve it. Then before you know it whatever tool they want to use has more bells and whistles than the average mars lander and does everything short of curing cancer. There's rarely any good correlation between the problem and the solution. That gap can just be bridged by buzzwords. The true correlation is usually between the solution and whatever the most senior dev on the team thinks is shiniest at the moment.