At "large financial news company" we had a "designed for the CV" tag that applied to stupid architectural decisions (of which there were many)
One of the biggest and most expensive was using Cassandra to store membership details. Something like 4 years of work, by a team of 40, wasted by stupid decisions.
They included:
o Using Cassandra to store 6 million rows of highly structured, mostly readonly data
o hosting it on real tin, expensive tin, in multiple continents (looking at >million quid in costs)
o writing the stack in java, getting bored, re-writing it as a micro service, before actually finishing the original system
o getting bored of writing micro services in java, switching to scala, which only 2/15 devs knew.
o writing mission critical services in elixir, of which only 1 dev knew.
o refusing to use other teams tools
o refusing to use the company wiki, opting for thier own confluence instance, which barred access to anyone else, including the teams they supported
I think the worst place I ever worked was like that. Was going back quite a number of years now but it was a startup fired up by a one of the lesser MBAs to utilise a legal loophole to slice cash off the public via a web app and a metric ton of marketing to desperate people.
Step one was hire everyone the guy had worked with at his previous company. They were all winforms / excel / SQL / sharepoint / office developers from big finance and had no idea where to go really. None of them had even touched asp.net.
Cue "what's popular". Well that was Ruby on Rails back then on top of MySQL and Linux. 4 people with zero experience pulled this stack in and basically wrote winforms on top of it. Page hits were 5-8 seconds each. Infrastructure was owned by SSH worms and they hadn't even noticed.
I think I lasted two days there before I said "I'm done".
I once saw a CEO who wrote his own Web Framework and forced the entire company to use it.
At the time, under the influence of React, the idea was to "build web application sorely based on Functional Programming". Since after years of trying no one could figure out what that meant, the company ditched the CEO and ended up wasting a couple years of work.
It's not that you don't write anything in a new thing. It's that you start with small, less critical projects. Get your feet wet, give people a chance to get a feel for the pros and cons, that sort of thing.
Jumping right into writing "mission critical services" in the brand new language that few people at the company know well is asking for trouble.
there were no problems of scale, speed or latency. It was migrating from one terrible system to something that should be smaller, simpler, cheaper and easier to run.
The API is/was supposed to do precisely four things:
o provide an authentication flow for customers
0 provide an authentication flow for enterprises to allow SSO
o handle payment info
o count the number of articles read for billing/freemium/premium
That is all. Its a solved problem. Don't innovate, do.
Spend the time instead innovating on the bits that are useful to the business and provide an edge: CRM, pattern recognition and data analytics.
One of the biggest and most expensive was using Cassandra to store membership details. Something like 4 years of work, by a team of 40, wasted by stupid decisions.
They included: o Using Cassandra to store 6 million rows of highly structured, mostly readonly data