[nabbed]

>Increased speed only gets us where we want to be sooner if we are also heading in the right direction.

I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, allowing you to iterate more quickly.

[msteffen]

I think “iterating more quickly” is good for the company doing the building. But if you’re the customer, having a new piece of shit foisted on you twice a day so that some garbage PM can “build user empathy” gets old really fast.

Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.

[ffsm8]

> Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.

And frankly, they were in point.

Especially in the B2B context stability is massively underrated by the product.

There is very little I hate more then starting my work week on a Monday morning and find out someone changed the tools I'm using for daily business again

Even if it's objectively minor like apples last pivot to the windows vista design... It just annoys me.

But I'm not the person paying the bills for the tools I'm using at work, and the person that is almost never actually uses the tools themselves and hence shiny redesigns and pointless features galore

[roughly]

It's still faster and cheaper to just build the right thing to begin with. As the old saying goes, spend your time sharpening your ax.

[mgfist]

Yes, but only if you have an ax to sharpen. With a lot of things it takes trial and error to make progress. You can take this pretty up high too - sometimes it takes building multiple products or companies to get it right

[Jare]

> With a lot of things it takes trial and error to make progress

Way too often that is used as an excuse for various forms of laziness; to not think about the things you can already know. And that lack of thinking repeats in an endless cycle when, after your trial and error, you don't use what you learned because "let's look forward not backward", "let's fail fast and often" and similar platitudes.

Catchy slogans and heartfelt desires are great but you gotta put the brains in it too.

[diatone]

Without commenting about the frequency of negligence myself, I suspect at least that you and GP are in agreement.

I doubt GP is suggesting ‘go ahead and be negligent to feedback and guardrails that let you course correct early.’

Plugging the Cynefin framework as a useful technique for practitioners here. It doesn’t have to be hard to choose whether or not rigorous planning is appropriate for the task at hand, versus probe-test-backtrack with tight iteration loops.

[mgfist]

I see indecision and analysis paralysis far more. And yes, you do need to thing about things, but far too often I see people not do something because they're worried it's not optimal. But not doing something is far worse than doing something sub-optimally!

[uoaei]

If you start a business without a concrete idea of the timber you need to achieve the idea you have, an axe will be all but useless.

[overfeed]

> I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing,

A lot of people are so enamored by speed, they are not even taking the time to carefully consider the full picture of what they are building. Take the HN frontpage story on OpenCode: IIRC, a maintainer admitted they keep adding many shallow features that are brittle.

Speed cannot replace product vision and discipline.

[johnnyanmac]

Tech very quickly shifted to a industry of marketers instead of hackers. And with salesmen, you want to advertise as many features as possible, not talk about how quality one good crucial feature is.

This won't really stop until investors start judging on quality and not quantity. But a lot of those are thinking in finances, and the thought of removing their biggest cost center is too tempting to not go all in on. So they want to hear "we made this super fast with 2-3 people!" instead of "we optimized and scaled this up to handle 400% more workload with double the performance".

[fc417fc802]

The outcome of that approach depends entirely on the broader process. Imagine golf but you refuse to swing with anything less than maximum strength to avoid wasting time.

Discovery is great and all but if what you discover is that you didn't aim well to begin with that's not all that useful.