Most active commenters
  • flail(7)
  • thenanyu(5)
  • scarface_74(4)

←back to thread

Development speed is not a bottleneck

(pawelbrodzinski.substack.com)
191 points flail | 17 comments | | HN request time: 0.001s | source | bottom
Show context
thenanyu ◴[] No.45138802[source]
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 just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed.

If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well.

If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.

replies(13): >>45139053 #>>45139060 #>>45139417 #>>45139619 #>>45139814 #>>45139926 #>>45140039 #>>45140332 #>>45140412 #>>45141131 #>>45144376 #>>45147059 #>>45154763 #
Aurornis ◴[] No.45139619[source]
> 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 that development speed has no impact at all. Add a dash of clickbait (putting "development speed" in the headline when they mean typing speed) and you get the standard LLM war clickbait article.

Both extremes are wrong, of course. Accelerating development speed is helpful, but it's not the only factor that goes into launching a successful product. If something can accelerate development speed, it will accelerate time to market and turnaround on feature requests.

I also think this mentality appeals to people who have been stuck in slow moving companies where you spend more time in meetings, waiting for blockers from third parties, writing documents, and appeasing stakeholders than you do shipping code. In some companies, you really could reduce development time to 0 and it wouldn't change anything because every feature must go through a gauntlet of meetings, approvals, and waiting for stakeholders to have open slots in their calendars to make progress. For anyone stuck in this environment, coding speed barely matters because the rest of the company moves so slow.

For those of us familiar with faster moving environments that prioritize shipping and discourage excessive process and meetings, development speed is absolutely a bottleneck.

replies(2): >>45140333 #>>45147277 #
1. flail ◴[] No.45140333[source]
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 use vibe coding a lot in prototyping. Depending on the context, we sometimes have a lot of AI-agent-generated code, too.

What's more, because of working on multiple projects, we have a fairly decent pool of data points. And we don't see much of speed improvement from a perspective of a project (I wrote more on it here: https://brodzinski.com/2025/08/most-underestimated-factor-es...).

However, developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though. See this: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... and this: https://substack.com/home/post/p-172538377

So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code.

But these are all just one dimension of the discussion. The other is a simple question: are there ways of validating ideas before we turn them into implemented features/products?

The answer has always been a wholehearted "yes".

If development pace were all that counted, Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening.

Incumbents are known to be losing ground, and old-school behemoths that still kick butts (such as IBM) do so because they continuously reinvent their businesses.

replies(3): >>45140496 #>>45140889 #>>45141668 #
2. thenanyu ◴[] No.45140496[source]
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.
replies(1): >>45141330 #
3. scarface_74 ◴[] No.45140889[source]
BigTech is “beating startups”. 99% of all startups are just acquisition plays with no real business model.

Check out all of the bullshit “AI” companies that YC is funding.

BigTech is not “loosing ground” all of them are reporting increasing revenues and profits.

replies(1): >>45142126 #
4. flail ◴[] No.45141330[source]
Sure. And yet, last time I checked, we've had plenty of applications for maps.

I like this metaphor. Looking at a map, we may get a pretty good understanding of whether it's a place we'd like to spend time, say, on vacation.

We don't physically go to a place to scrutinize it.

And we don't limit ourselves to maps only. We check reviews, ask friends, and what have you. We do cheap validation before committing to a costly decision.

If we planned vacations the way we build software products, we'd just go there (because the map is not the territory), learn that the place sucks, and then we'd complain that finding good vacation spots is costly and time-consuming. Oh, and we'd mention that traveling is a bottleneck in finding good spots.

replies(1): >>45142044 #
5. com2kid ◴[] No.45141668[source]
I needed to make a landing page for an ad campaign to test out an idea for PMF.

Claude crapped out a workable landing page in ~30 seconds of prompting. I updated the copy on the page, total time less than an hour.

The odds of me spending more than an hour just picking a color theme for the page or finding the SVG icons it used is pretty much 100%.

------------

I had a bug in some async code, it hit rarely but often enough it was noticeable. I had narrowed down what file it was in, but after over an hour of staring at the code I wasn't finding it.

Popped into cursor, asked it to look for async bugs in the current file. "You forgot to clean up a resource on this line here."

Bug fixed.

------------

"Here is my nginx config, what is wrong with the block I just added for this new site I'm throwing up?"

------------

"Write a regex to do nnnnnn"

------------

"This page isn't working on mobile, something is wrong, can you investigate and tell me what the issues may be?"

Oh that won't go well, all of the models get super confused about CSS at some point and end up in doom spirals applying incorrect fixes again and again.

> Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening.

This is already a well explored and understood space, to the extent that big tech cos have at times spun teams off to work independently to gain the advantage of startup-like velocities.

The more infra you have, the more overhead you have. Deploying a company's first service to production is really easy, no infra needed, no dev-ops, just publish.

Deploying the 5th service, eh.

Deploying the 50th service, well by now you need to have a host of meetings before work even starts to make sure you aren't duplicating effort and that the libraries you use mesh with the department's strategic technical vision. By the time those meeting are done, a startup will have already put 3 things into prod.

The communication overhead within large orgs is also famously non-linear.

I spent 10 years working at Microsoft, then 3 years at HBO Max (lean tech company 200 engineers, amazing dev ops), and now I'm working at startups of various sizes.

At Microsoft, pre-Azure it could take weeks just to get a machine provisioned to test an idea out on. Actually getting a project up and running in a repo was... hard at times. Build systems were complex, tooling was complex, and you sure as hell weren't getting anything pushed to users without a lot of checks in place. Now many of those checks were in place for damn good reasons, wrongly drawn lines on a map inside Windows is a literal international incident[1], and we had separate localizations for different variants of English around the world. (And I'd argue that Microsoft's agility at deploying software around the entire world at the same time is unmatched, the people I worked with there were amazing at sorting through the cultural and legal problems!)

Also if Google launches a new service and it goes down from too much traffic, it is embarrassing. Everything they do has to be scalable and load balanced, just to avoid bad press. If a startup hits the front page of HN and their website goes down from being too popular, they get to write a follow up blog post about how their announcement was so damn popular their site crashed! (And if they are lucky, hit the front page of HN again!)

The differences in designing for levels of scale is huge.

At Microsoft it was "expect potentially a billion users" At HBO it was "Expect tens of millions of users", at many startups it is "If we hit 10k users we'll turn a profit and we can figure out how to scale out later."

10K DAU is a load balances and 3 instances of NodeJS (for rolling updates) each running on a potato of a CPU.

> So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code.

I've worked in those environments, and the level of engineering quality can be much higher. The number of bugs that can be hammered out and avoided in spec reviews is huge. Technology designs that end up being servicable for years to decades instead of "until the next rewrite". The actual code tends to flow much faster as well, or at least as fast as it can flow in the large sprawling code bases that exist at big tech companies. At other times, those specs are needed so that one has a path forward while working through messy legacy code bases.

Both styles have their place - Sometimes you need to iterate quickly and get lots of code down and see what works, other times it is worth thinking through edge cases, usage scenarios, and performance characteristics. Heck I've done memory bus calculations for different designs, when you are working at that level you don't just "write code and see what works", you first spend a few days (or a week!) with some other smart engineers and try to narrow down the potential field of you should even be trying to do!

[1]https://www.upi.com/Archives/1995/09/09/Microsoft-settles-In...

replies(1): >>45142258 #
6. thenanyu ◴[] No.45142044{3}[source]
The best way to know if you would like a new restaurant or experience is to actually try it. We rely on reviews and maps and directories because trying it is too costly. If trying it wasn't costly, we would just try it instead of relying on proxies.
replies(1): >>45147287 #
7. flail ◴[] No.45142126[source]
Of course, Big Techs have leverage of their bottomless coffers. What they can't develop, they buy. What was the last successful product idea coming from, say, Facebook?

Or on a smaller scale, what's the last genuine Attlassian success?

Yet, when it comes to product innovation, the momentum is always on the side of the new players. Always has been.

Project management/work organization software? Linear. Async communication? Slack. Social Media? TikTok. One has to be curious how Zoom is doing so well, given that all the big competition actually controls the channels for setting up meetings. Self-publishing? Substack. Even with AI, everyone plays catch-up with Sam Altman, and many of the most prominent companies are newcomers.

We could go on and on.

Yes, Big Techs will survive because they have enough momentum to survive events such as the Balmer-era MS. But that doesn't mean they lead product innovation.

And it's expected. Conflicting priorities, growing bureaucracies, shareholders' expectations, old business lines (and more), all make them less flexible.

replies(1): >>45142383 #
8. flail ◴[] No.45142258[source]
Big Techs do have ways of rolling out new services step by step.

Paul Buchheit's stories about Gmail and AdSense are good examples. I was an early Gmail user when it was invitation-only and invitations were scarcely distributed (only as fast as the infrastructure could handle).

So, while I understand the difference in PR costs, it's not like they don't have tools to run smaller experiments.

I agree with the huge bureaucracy cost. On the other hand, they really have (relatively) infinite resources if they care to deploy them. And sometimes they do. And they still fail.

They often fail even when they try a Skunk Works-like approach. Google Wave was famously developed as a corporate Lean Startup (before there was Lean Startup). It was a disaster. Precisely because they did close to zero validation pre-release.

A side note, a huge flop it was (although Buzz and Google+ were bigger), it didn't hurt them long term in PR or reputation.

replies(1): >>45142841 #
9. scarface_74 ◴[] No.45142383{3}[source]
Again let’s look at YC’s latest batch of companies. How many of them are doing anything “innovative”?

An innovative product is one where customers in aggregate are willing to pay more for it than it costs to create and run. Any idiot can sell a bunch of dollar bills for 95 cents.

Going back to the latest batch of YC companies, there value play can easily be duplicated by any company in their vertical either by throwing a few engineers on it or creating a statement of work for the consulting company I work for and I can pull together a few engineers and knock it out in a few months and they will already have customers to sell it to.

There was one recent YC company (of course one of the BS AI companies) that was a hiring a “founding full stack engineer” for $150K. It looks like they were two non technical “serial entrepreneurs” without even an MVP that YC threw money at.

You can’t imagine how many times some hair brain underfunded startup reached out to me to be a “CTO” that paid less than I made as a mid level employee at BigTech with the promise of Monopoly money “equity”.

replies(2): >>45142996 #>>45147886 #
10. com2kid ◴[] No.45142841{3}[source]
Google had 3,000 employees when Gmail launched. Now they have over 100,000 employees!

People criticize Microsoft's historical fiefdom model, and it had its issues, but it also allowed orgs to find what worked for them and basically run independently. Of course it also had orgs fighting with each other and killing off good products.

Xbox was also a skunk works project at Microsoft (a few good books have been written about it!) and so was Microsoft Band. Xbox succeeded, Band failed for a number of reasons not related to the product or execution itself. (Politics and some historical corporate karma).

IMHO the only company good at deploying infinite resources quickly is Apple. 1 billion developing the first Apple Watch (Microsoft spend under 50 million on two generations of Band!) and then they kept going after the market, even though the first version was kinda meh. In comparison Google wear was on again of again for years until they finally took it seriously recently. I'm sure they spent lots of $, but the end result is nowheres near what Apple pulled off.

replies(1): >>45147998 #
11. thenanyu ◴[] No.45142996{4}[source]
VCs generally expect some small single digit % of their companies to succeed and return the fund

If 90% of the companies fail or are outright fraudulent it doesn’t really matter

replies(1): >>45143296 #
12. scarface_74 ◴[] No.45143296{5}[source]
And how many of those “succeed” by creating good products compared to just being acquihires where after acquisition you soon see a blog post about “our amazing journey”?
replies(1): >>45143323 #
13. thenanyu ◴[] No.45143323{6}[source]
Single digit percentage, like I said. Often low single digits
14. flail ◴[] No.45147287{4}[source]
OK, let's assume you can get food for free (or close enough). Like if you were super rich, and the cost was absolutely marginal for you.

How many dinners a day can you have?

You would still rely on alternative proxies, like recommendations or reviews.

15. flail ◴[] No.45147886{4}[source]
The last YC batch was like ~170 companies, correct? Each year, there are like 150 million startups. So let's not take YC stable for the whole startup ecosystem.

And I'm with you with a critical view on their all-in move toward AI. It's just what all the VCs do, and it's hard to say who's parroting who in this setup (I think that others are parroting YC, but feel free to challenge me on that).

Having said all that, I wouldn't be surprised if a couple of companies from this year's cohort made it big. If you look at YC's biggest successes year by year, you will often (but not always) find a household name.

Was there anyone who predicted these would be the greatest hits? Of course not! That's the whole point of having an investment portfolio. You can be wrong a lot of times if you secure an early investment in a unicorn every other year or so.

Also, "one recent example" of poor investment decision doesn't invalidate 2 decades of rather successful investment portfolios (as a whole, not individually).

In no way is it a YC defense. I'm very critical of the whole startup funding ecosystem, and they are a prominent player. Yet, if they were consistently stupid with their decisions, they wouldn't exist, let alone be the most desired accelerator out there.

Also, if it's that simple to copy what they do and what the companies in their portfolio do, why wouldn't Google et al. take their almost infinite funds and get the competing offers for non-BS ideas up and running in no time?

I bet that if you had an idea that could pay off thousandfold, you'd get enough eager ears to hear you out in any big tech. And still, it's the makeshift mass of startups that come through with new products.

One has to wonder why things like Shopify, Stripe, Zapier, or Figma did not come from the big tech. Each would have an ideal match. Even if you look at the AI landscape, how come Lovable made such a career? After all, they repackage the AI capabilities rented elsewhere. Somehow, with all the ingenuity of building ChatGPT, OpenAI and the rest didn't get it.

replies(1): >>45152579 #
16. flail ◴[] No.45147998{4}[source]
Sure, it was way easier to move at Google in the early 2000s than it is now. Yet, one has to admit they still keep trying. The list of products that they tried and killed doesn't show signs of stagnation: https://killedbygoogle.com/

And that's only the things that they have released. I'd bet that there are lots more that never make it to the public.

And I expect no less from Microsoft, by the way. Microsoft is, in fact, a great case in point of how failed releases don't hurt the company's PR long-term. How many failures have they scored trying to catch up with the missed opportunities of the 2000s? Smartphones & tablets, search, music players, social media.

They were late to move the Office to the cloud, and kept pumping dollars into the Explorer/Edge lost cause, too.

I don't know enough details, but Xbox seems more like an outlier than a norm.

Yet they rebounded with Azure and made some good bets with AI, and are doing better than ever. However, we don't see a stream of new product bets coming from them.

Oh, and on Apple: I wouldn't discount the role of cult-like following in repeated product success. Neither of the other big techs has such a relationship with its user base. You don't see many raving fans of Facebook or Google. And you definitely have millions of people who would buy any new Apple product simply because it is a new Apple product.

It's like Joel Spolsky but on a global scale. In the 2000s, whatever Joel Spolsky touched turned into gold. Stack Overflow? Check. Trello? Check. Was there something unique about these products? Details, sure. But the biggest thing was Joel's leverage.

Having run a highly popular blog for developers, he could instantly reach out to his early adopters. Given that many of the readers were actual fans, they'd jump on the opportunity, whatever it was. So the early traction was not a problem (which was especially crucial for the developers' forum).

Scale that up to the big tech context, and you get Steve Jobs.

A side note: I wonder how long it will take Tim Cook to dismantle that. You can already see cracks.

17. scarface_74 ◴[] No.45152579{5}[source]
Let’s look at YCs “successes” as far as the companies that have gone public.

https://medium.com/@kazeemibrahim18/the-post-ipo-performance...