Hacker News Reader

Comment by andrewstuart | Hacker News Reader

>> coding was never the bottleneck

What utter twaddle.

I’m old enough to remember pre AI programming and it very very much was the bottleneck.

I think it was indeed the bottleneck, however the assumption that "coding is the bottleneck" was baked into how organizations were measured, optimized, staffed for the last couple of decades.

From "The Mythical Man-month" (1995 ed)

  For some years I have been successfully using the following rule of thumb for scheduling a software task:
    l/3 planning
    l/6 coding
    l/4 component test and early system test
    l/4 system test, all components in hand.

The separation can be blurred if you follow an iterative approach (also explained in the book), but it aligned roughly with my experience. And whenever I helped a colleague in the past, coding was not the problem. It was either the lack of planning (no data modelling, no rough algorithm design), or no test setup (trial and error coding). It was never the coding part. Syntax errors is trivial to solve (with any good editor) and most libraries have good reference docs (not learning the library is an orthogonal matter).

AI practically zeroes out the coding and component test part of the process and massively accelerates the system test. What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback. With a fully optimized process, knowing what to build is nearly the entire problem.

> AI practically zeroes out the coding and component test part of the process and massively accelerates the system test.

Have this been measured, not comparatively, but absolutely? Where you plan, but don't code, instead leave the task to an agent (while you do something else), then test the result (maybe a quick look at the code), and ship. Is it sustainable? Or is it for greenfield setup and common ideas (things you would use tooling and snippets before)?

> What's left is "planning" which under a modern iterative model apparently includes deployment/distribution and getting/understanding/incorporating feedback.

That is not "planning" means. Planning is usually understanding, research, and design.

That's nice, but not authoritative for ~20 years (since before VMs and AWS). This book was before CI was commonplace.

If anything, testing/TDD is a bigger share compared to coding than before. LLMs can write tests too, but it's still something that has to be managed.

It meshes with my experience. Coding was never the bottleneck. Understanding what the customer/business wanted or needed was always the vast majority of the time spent on a project. A developer might not have seen that, depending how the organization worked. If you got specs from a manager you might not have been aware that those were 6 months in the making. If most of what you experienced was writing code then that could feel like the bottleneck especially if your manager demanded frequent status reports.

Doesn't matter. Nothing has fundamentally changed since he wrote it, because the book is more about how people act than technology.

Say what you want about reducible fractions but that's a pretty nonintuitive way to describe how you divvy up time. Weird to not use percentages or a common denominator...

I think it would be funny if the fractions summed to more than 1. Like the old joke: "the first 80% of the project takes 80% of the time, and the last 20% of the project also takes 80% of the time."

> old enough to remember pre AI programming

So old enough the remember the ancient times back in 2023?

Where did 2023 come from?

The Heuristic Compiler, dating back to the early 1960s, is generally considered the first instance of AI programming.

Maybe you mistakenly confused AI with a particular AI technology, like LLMs? But even then we had LLM-based code completion tools in 2020.

Is 2023 when you became old enough to start remembering things?

Reply on news.ycombinator.com