Hacker News new | ask | show | jobs
by dimal 404 days ago
I saw one startup with about fifty engineers, and dozens of services. They had all of the problems that the post describes. Getting anything done was nearly impossible until you were in the system for at least six months and knew how to work around all the issues.

Here’s the kicker: They only had a few hundred MAUs. Not hundreds of thousands. Hundreds of users. So all this complexity was for nothing. They burned through $50M in VC money then went under. It’s a shame because their core product was very innovative and well architected, but it didn’t matter.

3 comments

> They only had a few hundred MAUs

Way too many companies believe they're really just temporarily embarrassed BigTech.

Bad software dev. degrees that focus on fancy architecture that brings nothing to the table except overhead.
I don't think I learned basically anything about "fancy architecture" from my undergraduate courses except, ironically, reasoning about coupling and overhead.
I don't remember one solitary lecture on CI/CD, microservices, or even just deployment in general, in Uni. The closest that our comp. sci. classes ever came to touching on anything but the code itself was making us use SVN.
The difference between a software dev degree and a comp. sci degree.
I've never heard of or seen a Software Development bachelors degree?

I've seen Information Systems programs, that are usually CE, after-hours tracks. Neither Harvard, Yale, nor MIT have a software dev one, just Comp. Sci. I'm calling BS (no pun intended) on "software dev degrees" as a thing distinct from CS in any widespread fashion.

https://www.harvard.edu/programs/

https://admissions.yale.edu/majors-and-academic-programs

https://facts.mit.edu/degrees-majors/

I have worked with a company with ~100k MAUs with ~4 teams, even then it often feels the system is over-microserviced (about two dozen services I think).

Definitely some stuff makes sense (especially since it has a lot of IoT stuff), but micro-service added was used mostly as a way to develop new stuff without having to deal with the legacy monolith. The core of the application could easily be a single service backed by one big RDBMS with a few ancillary services around it.

The legacy monolith is still there kicking and screaming, it didn't need "breaking up" it needed (and I assume still do) need a major refactoring.

I’m not sure where’s the downside. The engineers got paid, they managed to put “founder” on their cvs, and enjoyed the ride. Now they are more prepared for their next adventure. The only ones who lost money were the investors, but nobody cares about them.
Do you not care about the users either? They too will lose the service if the company shutters.