Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

Post reply on HN
Print view View original

321–330 of 482 posts

Re: What software engineers can learn from the rapid collapse of Fast

#321

Post by randomdata »

zozbot234 wrote: post #132
lolsoftware wrote: post #33

Earlier quoted context omitted.

The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.

Tailscale's "database from 2022" is neither here nor there. What you should do in this situation is use the most boring tech, such as PostgreSQL with a simple HA setup. Thus avoiding the "play with nifty toys" trap and maximizing the chance of making appropriate choices.

The most boring tech imaginable would be a file. Perhaps containing JSON or similar structured data that can be handled using commonly available libraries. Which is exactly what they used for a long time.

I've done something similar before and it saved countless hours wasted on configuring databases, writing queries, fighting impedance mismatches. Postgres brings a lot of work. With a file you just need a couple of lines to write your memory out to a file and a couple more to read it back. Simple and effective.

Until it stops scaling, but at that point you've established that your business is successful enough that it warrants the effort of doing something shiny. Postgres has a place in this world, but no need to put the cart before the horse.

Re: What software engineers can learn from the rapid collapse of Fast

#322

Post by mwcampbell »

myrandomcomment wrote: post #314
geoduck14 wrote: post #240

Earlier quoted context omitted.

>Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue. YES! This is VERY true

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted t…

> Not something we could fix by tossing HW at the issue.

I'm curious to learn why, if there's any more you can share. What about vertical scaling, i.e. bigger machines instead of more of them? Can't that go pretty far?

Re: What software engineers can learn from the rapid collapse of Fast

#323

Post by lostcolony »

tootie wrote: post #206
kevan wrote: post #95

Earlier quoted context omitted.

It's not just limited to startups. When my business unit in Amazon spun up we hired way too fast and ended up having a harder time shipping v1 of the product than if we would've started lean and grown organically. We ended up spending a lot of time on a modularized platform to enable ~5 matrixed feature teams to contribute across iOS and Android apps. Looking back, a small dedicated team for iOS and another team for…

There's always misalignment incentives. If you put a tech manager in charge they're going to look for tech solutions that increase their head count.

Not really. Managers don't have incentives to grow their team size; they have incentive to deliver. And Amazon is known for 'two pizza teams' anyway.

The parent mentioned 5 teams instead of 2. That's director or higher level decisioning. Which is where you frequently end up having someone far enough away from the actual work that needs to be done, starting early to come up with a roadmap. Given fixed deadline and fixed scope, you lean on your PM triangle knowledge and try to get as much headcount as possible to ensure success, because you don't have enough knowledge yet to really decide at what point adding headcount leads to a negative gain. It's usually less about empire building and more about trying to plan things early rather than growing in response to need.

I've been in this situation, as a manager, being told to hire three teams (two being teams of contractors), pushed back to say I should hire only one (the FTE team) as we didn't have enough work for them, was rebuffed and told I needed to hire (the roadmap said we had the work!), hired, and then had leadership panicking about the fact the teams were idle with nothing to do. After a couple months had enough work we could split it (unnecessarily finely) between them so they could all look active, which lasted about a month before the FTE team just started doing it all, as that was more efficient. I didn't stay there long.

Re: What software engineers can learn from the rapid collapse of Fast

#324

Post by lostcolony »

ChrisMarshallNY wrote: post #198
hn_user82179 wrote: post #192

Earlier quoted context omitted.

Additionally, it's a bigger loss felt when that person leaves.

...which is why it's so important to foster an environment, where they don't want to leave. I kept engineers (really good ones) for decades . They had many "life problems" (like divorce, cancer, etc.) during that time, and I kept them on. It's entirely possible. I have done it. I ran a team that was all "top-shelfers."

You still should avoid being too siloed. Bus factor matters; their life problems you might be able to keep them, but you're ensuring you suffer death problems the same time they do.

Re: What software engineers can learn from the rapid collapse of Fast

#326

Post by randomdata »

Aeolun wrote: post #243
lupire wrote: post #175

Earlier quoted context omitted.

> The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. I've seen this repeated on HN, but never saw the alleged flak.

It’s a post from around a week ago. They went from embedded JSON, to something else (equally crazy), to embedded JSON again. Lots of laughs were had (and a lot of, just use postgres).

> They went from embedded JSON, to something else (equally crazy), to embedded JSON again.

They went from a JSON file, to etcd, to SQLite. etcd seems a little misplaced, but presumably it was already in their infrastructure and they thought they could save time leveraging it. The file-based approach seems appropriate for their particular use-case, though. It's not like it's a Rails app.

Re: What software engineers can learn from the rapid collapse of Fast

#327

Post by jthrowsitaway »

dmje wrote: post #318

Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

What point are you suggesting with your Nepal example? It's a third world country. Fast presumably employed people in San Francisco. That weekly wage from Nepal might buy you a bag of apples from Costco here. An entire year's worth of wages in Nepal might pay for one month's rent of basic housing.

Sure, nobody needs $250k per year to survive. CEOs also don't need to have an obscene compensation ratio compared to their workers. Health care companies don't need to rake in billions in profits every quarter. Sitting congress people don't need to conduct stock trades worth hundreds of millions every year. But here we are.

Companies paying everyday employees competitive wages in a free market is way down on my list of things to lose sleep over. We have a few other systemic issues I'd like to see solved first.

Re: What software engineers can learn from the rapid collapse of Fast

#328

Post by enra »

b20000 wrote: post #312
JumpCrisscross wrote: post #303

Earlier quoted context omitted.

> How on Earth did the company raise so much money with so few milestones of any kind being achieved? Fast pitched itself as taking the prudent path compared with e.g. Bolt. The latter went for big clients first. Fast started with small businesses. There were clearly other issues. But the closing era of cheap capital favoured the bold, and Bolt’s seizure of the fertile low grounds cut off Fast from its growth. Despit…

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

VCs sometimes follow "hot" companies. Companies become hot when several VCs think they are hot for whatever reason. When the company is hot and gets offers, other VCs will rush to give them more offers and at that point you might not even need a deck or any metrics anymore. The startup can then bid those offers against each and can end up raising even more they initially were trying to.

Fast did great job hyping the company on Twitter, likely the founder also was a good storyteller. The old adage is that you raise with a story, team or traction. Sometimes the story actually pans out, like with YC Airbnb is often an example of company that struggled for a long time in the beginning and no-one could really predict how big they could become.

Re: What software engineers can learn from the rapid collapse of Fast

#329

Post by jthrowsitaway »

GianFabien wrote: post #271

Back of torn envelope calculation: 450 staff, 150 engineers = 300 managers? $600k revenue in 2021 => barely paid for their salaries at $200k each. What were they really doing? Going on junkets to Florida - yeah, that'll generate more revenue.

> 300 managers

Uhm... Sales, marketing, finance, HR, legal, designers, QA, etc. Companies aren't just made up of engineers and people to manage those engineers.

Post reply on HN