I once wasted several months of schedule and payroll wrestling to improve a DNN model - which resulted in that model getting much much better thanks to tons of creative and interesting work.

We swapped the learned model for a perfect a oracle and realized the actual problem was elsewhere in the system and was easily fixed. None of those model enhancements were needed.

Not the person you asked, but working on remote sensing and perception I have seen (not once) the teams turning from improving use of available sensor data to things like cutting edge messaging technologies to support real-time data delivery from thousands of sensors (when they have three sensors today and might get another one next year and their current simple streaming will work just fine for up to 20).

While those are interesting problems they have nothing to do with their current perception challenges (that have to be solved for a successful deployment), steal resources from the team and make life harder for a few remaining people actually working to solve current challenges, as they now need to switch to a more complex messaging and rewrite some of their existing utilities.

These weren't fatal to the project or team, but did contribute extra work for net negative value (slower & more maintenance, with no relevant extra features):

- Using Kubernetes to host an application when Docker Compose would do (specialist application with <10 concurrent users).

- Using DynamoDB to store a few kB of temporary data in a processing pipeline, despite having several existing PostgreSQL instances already and no DynamoDB ones.

Years ago, my team at AWS considered writing our own declarative language to configure EC2 instances which would replace some old functionality within CloudFormation (cfn-init) until I pointed out you could achieve the same thing with our existing features (State Manager Ansible playbooks)

Approximately 100.0% of all Hadoop installations.

I worked at a place where they finally ditched their Hadoop project after a couple of years and who knows how much money. Only to implement a big Kubernetes cluster instead, where they four years later have burned through three different commercial Kubernetes distributions.