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

Development speed is not a bottleneck

pawelbrodzinski.substack.com

Post reply on HN
Print view View original

61–70 of 153 posts

Re: Development speed is not a bottleneck

#61

Post by thenanyu »

epolanski wrote: post #59
thenanyu wrote: post #11

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…

I don't buy it. Prototyping was never the issue. The lessons you're talking about come from stressing applications and their design, which requires users to stress it.

So give it to users?

Re: Development speed is not a bottleneck

#62

Post by thenanyu »

giancarlostoro wrote: post #43
trjordan wrote: post #18

Earlier quoted context omitted.

This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, imp…

I can agree with this sentiment. It does not matter how insanely good LLMs become, if you cannot assess it quickly enough. You will ALWAYS want a human to verify and validate, and test the software. There could be a ticking timebomb in there somewhere. Maybe the real skynet will kill us with ticking time bomb software bugs we blindly accepted.

In most scenarios I can tell you if I like or dislike a feature much faster than it takes a developer to build it

Re: Development speed is not a bottleneck

#63

Post by bob1029 »

hombre_fatal wrote: post #35
throwaway-18 wrote: post #12

Earlier quoted context omitted.

The difference between Software Engineers (or Developers) vs Programmers; with the latter designation being a stretch for some.

I think we should we put this title-based distinction to rest. Whether you call yourself an engineer, developer, programmer, or even a coder is mostly a localized thing, not an evaluation of expertise. We're confusing everyone when we pretend a title reflects how good we are at the craft, especially titles we already use to refer to ourselves without judgement. At least use script kiddie or something.

In my local world: Writing code to specification is programming. Writing the specification is engineering.

Re: Development speed is not a bottleneck

#64

Post by thenanyu »

flail wrote: post #56
Aurornis wrote: post #31

Earlier quoted context omitted.

> It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. The current trend in anti-vibe-coding articles is to take whatever the vibe coding maximalists are saying and then stake out the polar opposite position. In this case, vibe coding maximalists are claiming that LLM coding will dramatically accelerate time to market, so the anti-vibe-coding people feel like they need to claim…

Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly). I've worked in the corpo world, too, and it is anything but. We do…

The map is not the territory. Validating against anything other than the actual feature is a lossy proxy. It may be an acceptable tradeoff because building the feature is too costly but that’s the whole discussion at hand.

Re: Development speed is not a bottleneck

#65

Post by bob1029 »

thenanyu wrote: post #61
epolanski wrote: post #59

Earlier quoted context omitted.

I don't buy it. Prototyping was never the issue. The lessons you're talking about come from stressing applications and their design, which requires users to stress it.

So give it to users?

There is often a severe opportunity cost associated with experimenting on your customer base.

Re: Development speed is not a bottleneck

#66

Post by seneca »

croes wrote: post #60
seneca wrote: post #47

Earlier quoted context omitted.

Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a n…

> trying different things until something works That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.

Sure, and that is more my own clunky paraphrasing than anything the article states. Iterating and testing to find a fit for customers is the business/product side of software. How you execute on those iterations is engineering.

Re: Development speed is not a bottleneck

#67

Post by thenanyu »

franktankbank wrote: post #41
thenanyu wrote: post #11

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is ju…

Feedback from customers is the longest time.

Get it sooner then! By getting to market faster

Re: Development speed is not a bottleneck

#68

Post by croes »

seneca wrote: post #66
croes wrote: post #60

Earlier quoted context omitted.

> trying different things until something works That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.

Sure, and that is more my own clunky paraphrasing than anything the article states. Iterating and testing to find a fit for customers is the business/product side of software. How you execute on those iterations is engineering.

But the business/product side is the shallow side, customers rarely care about what happens behind the curtain. And most customer needs are pretty similar in the backend

Re: Development speed is not a bottleneck

#69

Post by thenanyu »

flail wrote: post #58
seneca wrote: post #47

Earlier quoted context omitted.

Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a n…

If only "trying things" always equaled "developing things". There's a whole body of knowledge (under the Lean Startup umbrella) that argues otherwise. Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)? Even more so, do we have to build a fully-fledged version of it to know? If yes, then I agree, development is the bottleneck.

The lean startup offers a lot of lossy proxies for building and releasing things because it presupposes that building things takes a long time

Re: Development speed is not a bottleneck

#70

Post by thenanyu »

croes wrote: post #60
seneca wrote: post #47

Earlier quoted context omitted.

Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a n…

> trying different things until something works That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.

Trying things and changing if it doesn’t work is the only way I know how to build software.

What would you do? Don’t change?

Post reply on HN