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

121–130 of 153 posts

Re: Development speed is not a bottleneck

#121

Post by estimator7292 »

flail wrote: post #93
thenanyu wrote: post #57

Earlier quoted context omitted.

The whole point of lean startup was to route around the bottleneck of development velocity.

I heard that before. No, Lean Startup is not about working around the cost of software development. It is about designing good experiments, validating, and learning, so that when we're down to development, we build something that's way more likely to succeed. The fact that we were advised to build non-technical experiments is but a small part. And with the current AI capabilities, we actually have a new power tool fo…

Distinction without a difference. Your SWE costs blow up because development velocity is low and labor is a fixed cost. You reduce costs by increasing velocity, which in this case is achieved by aiming your development better.

Move faster and move better (to move faster) are the same thing. You reduce costs by going faster, and with lean you go faster by avoiding time wasters.

Re: Development speed is not a bottleneck

#122

Post by IanCal »

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.

That doesn’t require developer time though.

Also that time is needed regardless, do you think it’s the majority of time related to releasing a feature?

Re: Development speed is not a bottleneck

#123

Post by wglb »

flail wrote: post #78
wglb wrote: post #45

Development speed has been a bottleneck in every major product development effort that I have been involved in. From a realtime medical data collection application where president and VP are drumming their fingers on the desk waiting for development to be finished. Writing a compiler at Sycor, there were teams waiting for us to finish our development. We were successful, being about an order of magnitude faster than…

Oh, I agree that in many companies, internally, we create perceptions that development is, indeed, THE bottleneck. VP of Product put all the pressure on dev teams to deliver all the features against the specs. Then they release the new product/new version with plenty of fanfare. And then literally no one measures which parts have actually delivered any value. I'd bet a big part of that code added no value, so it's a…

Disagree. My experience is that it is a measurable fact and not a created perception.

And few of us can usefully compare what we do with what amazon google Facebook or other giants do.

Good luck on flipping their script. Meanwhile I’ll be over here making book

Re: Development speed is not a bottleneck

#124

Post by khazhoux »

goalieca wrote: post #111
khazhoux wrote: post #83

Earlier quoted context omitted.

On the other hand, there’s tons of people here on HN who will claim that there’s zero connection between lines of code written and developer productivity. Obviously, deleting bad/unused code is good. And obviously, some tricky bugs are fixed in one line. But you can’t build something new without some (usually, very many) lines of code. No code -> no software.

What would be the function mapping lines of code to "value" look like. Most agile teams aim to deliver "value" these days. We can't put a number of value. We most certainly can't say on average that adding a single line of code adds 0.01 units of value for a certain project.

> We most certainly can't say on average that adding a single line of code adds 0.01 units of value for

Certainly there’s no simple F(num_lines_changed) value function. There are many other parameters. But to suggest, as many here somehow do, that lines of code touched is independent to effective development, is plain ludicrous.

Re: Development speed is not a bottleneck

#125

Post by wyum »

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 think you and the article actually agree and you are arguing only with their use of the word "development."

The article uses "development" to refer only to the part where code is generated, while you are saying "development" is the process as a whole.

You both agree that latency in the real-world validation feedback loop leads to longer cycles and fewer promising solutions and that is the bottleneck.

Re: Development speed is not a bottleneck

#126

Post by speed_spread »

ardit33 wrote: post #34

lol.... development speed and quality are both the bottleneck my dude. But if you have enough speed, you can fix quality issues as you are able to test and fix things faster. You have even CEO of car companies that get fired because they mess this up. Or even the Sonos company lost a lot of value, and got their CEO fired because they messed up and can't fix it in time. Speed is not everything. Developing the right fe…

Car companies cannot figure what to develop and how to develop it. They could develop 1000% faster and would still get it wrong. Mostly because they see software as a cheap alternative to metal and rubber and developers as degenerate primadonnas - i.e. not true engineers.

Sonos decided they wanted to centralize their architecture so they could tap into it to make extra surveillance money. They trashed things that worked perfectly and replaced them with a cloudshit architecture that nobody asked for and that _cannot_ deliver the same low-latency, quality experience as before. They could have developed things 1000% faster, they would have just drove a cliff sooner.

Even if people could write apps instantly, nothing would prevent them for being stupid and greedy.

Re: Development speed is not a bottleneck

#127

Post by tharkun__ »

add-sub-mul-div wrote: post #23
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 think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them.

I can't. The LLM (Claude Code really) is just too slow. It is just so slow at doing the things I ask it to do once I'm at the review stage.

Like the initial plan always sounds great and looks great. Then it goes to actually do the changes and proclaims victory after I left it alone doing other stuff, because it takes a while. Then I review what it did and what it didn't do and I inevitably find that it only did half of what it said it would do and did half of what it did do incorrectly despite what it told me what it would do.

The use case here is a large code base that needs changes. Not new feature development on a green field (or a green corner of an established product). And it's just so unbearably frustrating. It's like giving the task to a Junior on probation. I tell them something, they go off for 10 minutes and tell me they're done and I look and find seven holes I need to tell them to fix. But they aren't the Junior that picks up stuff and gets better and needs less supervision. Instead it seems like the context gets more and more polluted and the Junior gets closer and closer to failing his probation.

Many grey hairs added recently, because yeah, we also "have to be faster by using AI" now ...

Re: Development speed is not a bottleneck

#128

Post by tharkun__ »

daliusd wrote: post #116
no_wizard wrote: post #29

Earlier quoted context omitted.

The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so. That’s what slows me down with AI tools and why I ended up sticking with GitHub Copilot, which does not do any of that unless I prompt…

So you want Aider, Claude Code or opencode.ai it seems. I use opencode.ai a lot nowadays and am really happy and productive.

I really wanted to use Aider. But it's impossible. How do people actually use it?

Like, I gave it access to our code base, wanted to try a very simple bug fix. I only told it to look at one service I knew needed changes, because it says it works better in smaller code bases. It wanted to send so many tokens to sonnet that I hit the limits before it even started actually doing any coding.

Instant fail.

Then I just ran Claude Code, gave it the same instructions and I had a mostly working fix in a few minutes (never mind the other fails with Claude I've had - see other comment), but Aider was a huge disappointment for me.

Re: Development speed is not a bottleneck

#129

Post by daxfohl »

ACCount37 wrote: post #77
giancarlostoro wrote: post #43

Earlier quoted context omitted.

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.

The threshold of supervision keeps rising - and it's going to keep rising. GPT-2 was barely capable of writing two lines of code. GPT-3.5 could write a simple code snippet, and be right more often than it was wrong. GPT-4 was a leap over that, enabling things like "vibe coding" for small simple projects, and GPT-5 is yet another advancement in the same direction. Each AI upgrade brings forth more capabilities - with…

I could see it happening in a year or two. Especially in backend. There's only so many different architecture patterns we use, and an LLM will have access to every one that has ever been deployed, every document, every gripe, every research paper, etc.

I mean, I think ultimately the state space in designing a feature is way smaller than, say, go (the game). Maybe a few hundred common patterns and maybe a billion reasonable ways to combine them. I think it's only a matter of time before we ask it to design a feature, and it produces five options that are all better than what we'd have come up with.

Re: Development speed is not a bottleneck

#130

Post by himeexcelanta »

skydhash wrote: post #25
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…

Naur’s theory of programming has always felt right to me. Once you known everything about the current implementation, planning and decision making can be done really fast and there’s not much time lost on actually implementing prototypes and dead ends (learning with extra steps). It’s very rare to not touch up code, even when writing new features. Knowing where to do so in advance (and planning to not have to do that…

Typing syntax and dealing with language issues takes a lot of mental overhead that AI mostly solves in the right hands. It’s not zero!
Post reply on HN