Hacker News Reader

Comment by bruce511 | Hacker News Reader

I feel like one success story doesn't necessarily make it good advice for everyone else.

Maybe in the world where your customer base is flexible (students), and where your product "doesn't really matter", then hey, why not break it from time to time. The penalty for failure, is well, zero.

In a different context though small errors can result in very large penalties, even extinction. In which case this strategy will (and certainly has many times) failed.

Advice without context is dangerous. Before adopting any advice (especially "how we did it" stories from survivors) it's worth really understanding the external factors that aided in that success.

View on HN

> In a different context though small errors can result in very large penalties, even extinction.

But in practice, for startups it's almost never the case, and having this belief is actually harmful.

Backing up for a second, have you started a startup yourself, or know (have had a 1 hour, 1:1 convo with) anyone who started a startup for which that happened? If so I would like to hear the story.

Personally, I've started 4+ startups, 2 successful, and directly know dozens of startup founders. So I know many failed startups. None of them was due to a small error that resulted in large penalties. Most of them was due to lack of determination, or speed, or being too conservative if anything.

The above belief you have is so harmful for a startup not because it's wrong, but because it's so intuitive and drives startups in diametric opposite direction of success. By slowing down at each stage to do a "small errors" analysis you move a lot slower and fail by default. The fear of making a small error has killed more startups than just a small error.

The intuition is correct historically. Back when humans were in small tribes, if we lost our reputation, we would be outcast and lose our lives. For the startup world (and e.g. modern dating world), that intuition doesn't apply.

> Personally, I've started 4+ startups, 2 successful, and directly know dozens of startup founders. So I know many failed startups. None of them was due to a small error that resulted in large penalties.

> Most of them was due to lack of determination, or speed, or being too conservative if anything.

You simply don't get it, but most people don't, including founders. Lack of determination, speed, or being conservative, are the symptoms of those errors. They are second-order effects that cause third-order effects, and so on, in a vicious cycle. Maybe those founders learned those habits from a previous company, but at the root of it was a decision that wasn't given enough care.

They can be related to morale issues, resulting from small details or flaws adding up. Also from hiring decisions, stemming from again small details or flaws in that process.

Paul Graham said recently: https://twitter.com/paulg/status/1561566435012251648

> If you think people have scar tissue, you should see organizations. Each time there's a disaster, they create a process to prevent future disasters of that type. Eventually they accrete a thick layer of these processes that prevents them from moving. Then they die.

So you're saying entrenched companies become too conservative due to their over reactive policies and get slowed down to the point where they die? I'm really struggling to understand how you think this somehow contradicts what the person you're replying to said.

Alright, this is the part of the message in question, in case it wasn't clear:

> But in practice, for startups it's almost never the case, and having this belief is actually harmful.

Maybe they were thinking of startups in the earliest stages (before having any real number of employees, Pre-series A), but the failures in those situations are less nuanced, at least in this context - do they really need discussion? The article is clearly talking about companies that were not in the earliest stage at the time of the actions being discussed.

With all Paul's experience at large companies.... Honestly, what he thinks causes the death of large companies has to be taken with a helping of salt.

At what point was there any mention of a large company here?

It's funny that people (including me) see things that aren't there. I could have sworn it said "large organizations". My bad.

I have indeed started a company, but it was different then - we didn't have VC money to spend, so we built it from literally nothing. Our product has to calculate numbers, in a specific time frame. Failure to produce results on time, or excessive numbers of errors, (or excessive errors) can lead to significant issues for customers resulting is serious financial implications. That is my context.

I feel like the main thread of replies to my comment focused on the speed. Whereas perhaps I was commenting more on the "break things" aspect. We did, and still do, move quickly at times, and slower at others, but we work quite hard not to break things.

Our customers need our software to be reliable. It impacts them, and also (in a big way) their customers. They need it to work, not be broken.

That's my context. In my context breaking things is not OK. Your context may be different. My path is not necessarily good for you, your path is not necessarily good for me.

So I say it again - all advice can be useful, or harmful. Context matters. Make sure you understand your own context, and the context of the advice giver in deciding if the advice is worth anything.

Indeed, if my context is not your context, then my experience is of no value to you. So I agree with your first question;

>> have you started a startup yourself,

Discovering my context helps you understand my advice. That is a good instinct to have.

I wholeheartedly agree with your comment. The “move fast and break things” mentality works for the banal and unimportant, but not for the significant or important.

Who cares if a social media site is offline for a day? Society will be fine. Users will be fine. Is anyone really going to miss a random social media post lost due to misbehaving code? Probably not on balance.

But if you’re attempting to build a quality, say, EMR/EHR, or some kind of industrial control software, or a password manager, you have certain duties that are completely incompatible with that mentality.

Every time peoples life, health and well-being depend on your action advocating for "move fast and break things" should be reason for immediate termination. The severance package can be negotiated later.

While I agree with you generally, one could make the argument that if your aim is to drastically disrupt some domain, you may wish to adopt a riskier but faster path even if you're working in a safety-critical field, because the "slow and safe" route means more lives lost / negatively impacted while you slowly perfect your solution.

If you'd humor my extreme utilitarian view for a minute, I would argue both autonomous self driving and some medical endeavors could save many more lives if we, as a society, said "you get a budget of 10k. 10k lives you can severely negatively impact to deliver impact greater than that number" - basically giving you an investment/debt you repay to society via your future impact. Currently, traffic fatalities are at ~38k/year in the US (with over 2M/year injured), and the numbers for leading medical causes are staggering (heart disease ~700k/year, cancer ~600k/year, etc.). I would argue our current processes for breakthroughs in areas where health or safety are involved simply lean too far towards the "safe" end of the spectrum.

One anecdote I can share is a friend who worked for over a decade on a system where patients could buy a medical test at a pharmacy, take a urine sample at home, and get lab quality results using their phone's camera. The tech was ready in their first year of running. They built a suite of validations and tested things across hundreds of phone models, they really did their part well because they truly care. Getting things FDA approved and in patients' hands took much longer, because the processes are extremally slow and designed to reduce risk by almost all means necessary. While that's a good idea in theory, it didn't stop a scam like Theranos (because when you're intentionally dishonest rules don't always help), and it did make it so my friend's company took a lot longer before being able to get fast, accurate, test results for many different metrics to rural and poor communities where lab testing can be an issue...

Theranos isbthe exception proofing the FDA right, the 737 Max is the exception proofing the FAA right. And no, there is no such thing as a "budget" of lost lives to further innovation. That approach is just deeply cynic, and should ve in itself ground to not work in any of those industries. The 737 Max and Theranos do show so that there already to many people with that exact mindset out and about. And while Theranos didn't cause any death (at least not that I am aware of), the MAX indeed did. All for profit, all for moving fast. For me, that is simply not acceptable.

I agree with you fully. However, the way I read int0x2e’s comment was as a theoretical example of the logic they were putting forth. Not as advocacy for actually taking that tact.

Typically we empower governments with restraints to prevent them from allowing those tactics, and for good reason. (Even if in reality it is imperfect).

>> And while Theranos didn't cause any death (at least not that I am aware of), the MAX indeed did

The Max killed 346.

Theranos is directly related to 1 (Ian gibbons) but it is probable that the indirect number is much much higher. Between suicides for false positives, and lack of treatment for false negatives, there are significant outcomes.

Given that they delivered at least 150 000 incorrect results, I'm going to wildly speculate here that they are more deadly than Boeing.

Context matters. Good strategies for a social media company does not necessarily make it good advice for companies in another context. Turns out "breaking things" is not terribly good advice to airplanes or medicine.

> as a society, said "you get a budget of 10k. 10k lives you can severely negatively impact to deliver impact greater than that number"

10k negative impacts multiplied by every startup, most of which will never get to the stage where they’re able to deliver their “benefit”, and even then, how do we quantify whether it was worth the cost?

Worked to get into space with SpaceX. ULA is trying the old approach. We can look at the difference live.

None of the SpaceX ideas where actually that new, rockets lanfed already decades earlier. That ULA got complacent is a differwnt story, ULA is far from being the only competitor of SpaceX outside of US government launches.

Not tgat SpaceX isn't imoressive, it is. They did move woth less beauraucracy, not with more risk. Kind of like the Covid vaccines, less red tapes speeds things up. Otherwise, SpaceX seems to be rather conservative ubder Shotwell's leadership as far as safety is concerned.

Dpace flight is, funny enough, less regulated that commercial aviation and tue aero part of aerospace.

> Who cares if a social media site is offline for a day? Society will be fine. Users will be fine.

Not just fine... better off.

While what you're saying is generally true, one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes.

Github Actions went down yesterday, disrupting the service for thousands of companies. They also went down today.

And yet, if they didn't have the "move fast" mindset, they probably wouldn't have Actions as a product in the first place.

> one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes.

Perhaps that's true of software engineers but I don't think it's true for Professional Engineers. That's one of the reasons I wouldn't consider most people who call themselves software engineers to be an engineer at all.

'developer' and 'programmer' really are more apt terms - 'engineer' sounds more impressive though

So does vice president instead of manager or executive assistant instead of secretary.

Wait until you meet sales engineers

> ...That's one of the reasons I wouldn't consider most people who call themselves software engineers to be an engineer at all.

Few people who call themselves (non-software) engineers today are running locomotives. Words can evolve over time.

What does operating locomotives have to do with making sure the thing you're building follows all the rules and has appropriate safety factors and such?

Operating trains is literally the origin of "engineer". It was a job that required significant application of accepted rules and methods to calculate acceptable speeds for cornering, hill climbing, and hill descent, especially when they were all combined. Getting outside the acceptable speed ranges could be catastrophic in every single one of those cases, and acceptable speeds could vary significantly depending on weather, train length, and train weight. The job was all about understanding how to correctly apply all the rules and control the vehicle to stay within safety factors.

>Operating trains is literally the origin of "engineer"

That sounds pretty dubious to me.

https://en.wikipedia.org/wiki/Smeatonian_Society_of_Civil_En...

There were probably earlier usages of the term too. As the article says the Civil bit came about to distinguish themselves from the older profession of Military Engineers.

What "engine" do you think "engineer" is referring to?

A war machine. Engineer is an old name that existed long before trains.

https://en.wiktionary.org/wiki/engin#Old_French

Edit: Might have heard of the term "Siege engine" as well?

https://en.wikipedia.org/wiki/Siege_engine

Words do evolve. That’s why I said Profession Engineer rather than just engineer. It's a relatively new title (from early 1900's) and in lots of jurisdictions it implies the person is licensed and if something they stamp fails, they can be sued for malpractice and even lose their license to practice.

> one should also keep in mind that people (especially engineers) are extremely biased and tend to drastically overestimate the cost of mistakes

I've found the opposite to be true, especially with engineers moving from pure software to founding companies in regulated industries such as aerospace or medical devices.

Good point, though I'd say the major factor is dealing with hardware, not necessarily being regulated. You can't just push a hotfix to a million of on-premise devices with one click.

The challenge here is that many startups will ultimately fail to produce anything at the early stages. A big company/startup can spend months or even years debating the feature in question with minimal consequence.

The startups advantage is to simply be faster. A slow startup is worse off than a division in a big company.

> I feel like one success story doesn't necessarily make it good advice for everyone else.

Heh, reminds me of this tweet: https://nitter.net/apenwarr/status/1440656518701932554 / https://twitter.com/apenwarr/status/1440656518701932554

There are plenty of details in the OP that will be missed. Those who will fail will gloss over those details, will think that some of the advice doesn't apply to them, or is "only for bigger companies". I work with people like this. I have felt the pain. To them, the idea of speed means to sacrifice quality and to skip code reviews. Moving fast is not the software engineering equivalent of using a microwave oven to cook. Speed and quality are intertwined. They won't listen, and they won't learn except through failure.

The worst is when they tell you what you want to hear during the job interview process because you are a strong candidate, then the reality is the opposite. "We invest heavily in tooling to maximize productivity per engineer", for example. You need to press them for details, don't settle for a sound bite.

I think the article has sufficient advice, that if followed, will lead to big enough improvements to be worth it.

> "I feel like one success story doesn't necessarily make it good advice for everyone else."

I don't think the problem is with the advice giver, rather the receiver.

Reply on news.ycombinator.com