[bdangubic]

> Writing the code hasn’t been the bottle neck to developing software for a long time.

I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating.

I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only one) and we needed more people to write the code

[agentultra]

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.

I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.

You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.

This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.

The real bottle necks are people and releasing systems into production. Every line of code change is a liability. There’s risk tolerance to manage in order to achieve five-nines.

A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

[jordwest]

> they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours

Haha, this is exactly my experience.

I'll never forget the best candidate I ever interviewed - my feedback was to absolutely hire him and put him on the most interesting and challenging problems. They put him in a marketing team tweaking upsell popups. He left after 2 months.

[senko]

> If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster.

He didn’t say that. He said adding developers to a late project makes it slower, explained why, and even added some charts to illustrate it. The distinction matters.

By your interpretation, no company should have more than a few developers, which is obviously false. You can argue team organization, but that’s not what Brooks was saying, either.

On top of that, parent never said he hired 40 devs for one project at one time. He was talking in general terms, over the course of years, perhaps in multiple companies.

Finally, let me invoke another aphorism: hours of planning can save you weeks of development. Right here you have the bottleneck staring you into the face.

Of course it’s development. And unless you’re in a really dysfunctional environment, most of that development is coding, testing and debugging, where AI can help a lot.

[HarHarVeryFunny]

> He didn’t say that.

Actually he did, or something very close to it.

Obviously SOMETIMES you can add more developers to a project to successfully speed it up, but Brooks point was that it can easily also have the opposite effect and slow the project down.

The main reason Brooks gives for this is the extra overhead you've just added to the project in terms of communications, management, etc. In fact increasing team size always makes the team less efficient - adds more overhead, and the question is whether the new person added adds enough value to offset or overcome this.

Most experienced developers realize this intuitively - always faster to have the smallest team of the best people possible.

Of course some projects are just so huge that a large team is unavoidable, but don't think you are going to get linear speedup by adding more people. A 20 person team will not be twice as fast as a 10 person team. This is the major point of the book, and the reason for the title "the mythical man month". The myth is that men and months can be traded off, such that a "100 man month" project that would take 10 men 10 months could therefore be accomplished in 1 month if you had a team of 100. The team of 100 may in fact take more than 10 months since you just just turned a smallish efficient team into a chaotic mess.

Adding an AI "team member" is of course a bit different to adding a human team member, but maybe not that different, and the reason is basically the same - there are negatives as well as positives to adding that new member, and it will only be a net win if the positives outweigh the negatives (extra layers of specifications/guardrails, interaction, babysitting and correction - knowing when context rot has set in and time to abort and reset, etc).

With AI, you are typically interactively "vibe coding", even if in responsible fashion with specifications and guardrails, so the "new guy" isn't working in parallel with you, but is rather taking up all your time, and now his/its prodigious code output needs reviewing by someone, unless you choose to omit that step.

[senko]

>> He didn’t say that. > Actually he did, or something very close to it.

Yeah, the "something very close to it" is what I quoted. And I'll repeat: distinction matters.

> don't think you are going to get linear speedup by adding more people.

I didn't either say, nor imply, this. Of course communication and coordination is overhead. Let's quote Brooks from the same article some more: The maximum number of men depends upon the number of independent subtasks.

Which is why in modern times you have a bunch of theoretical and practical research around team topologies, DORA, Reverse Conway Manoeuvre, the push to microservices, etc, etc. You can boil all that down to "maximize team independence while making each team as productive as possible."

This is a wonderful tangent (and if this interests you, I heartily recommend the Team Topologies book), but can we just keep in mind the gp never actually said he was overhiring for a single project? Parent latched onto a wrong idea and ran with it.

[bdangubic]

> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.

I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying this, it is like saying "read this book, says that that Sun will rise tomorrow morning"

> I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.

I wasn't talking about startups or developers making boxes more blue, I was talking about personal experience. The bottleneck, if you are doing amazing shit and not burning some billionaries money on some silly "startup" is always the code which is why we hire developers to write the code. Everything else is just coming up with some silly unrelated examples - of course there are people (at every job again) doing nothing or menial tasks - this isn't what I was talking about.

> You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.

I do have customers that want features that would make their lives easier and are willing to handsomely pay for it, that good enough?

> This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.

This is only on super shitty teams with super shitty co-workers (especially senior ones) and super shitty managers. I feel for the careers in this industry where this is/was the case. A whole lot of people are terrible at their jobs in places like this - a whole lot of people...

> A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

a well-sized team was at one point (well-sized team - 1) and (well-sized team - 2) and (well-sized team - 3) and in the future if it is right team will be even more amazing as well (well-sized team + 1), (well-sized team + 2)

[Rury]

> new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team

This is true of training someone new to do a routine job. You spend some time teaching them, and they learning, and then that overhead of teaching/learning slowing you both down disappears.

But it's a little different with knowledge work, as the constant changes and creation of stuff means other team members have to constantly learn what you changed/created if they are to do anything with it. So you never reach this "well-oiled" state, unless you divy up the tasks so that the amount of information you need to deal amongst each other is minimal and unchanged. This principle even holds true in multithreaded programming as to performance, in that constant sharing and changing of data between threads can actually hurt performance in comparison to a single threaded process.

[agentultra]

If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you.

I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager.

The slow part isn’t writing code.

It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.

[dpark]

> If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you.

What someone says “I’ve heard this a thousand times, but…”, it could be that the person is just stupidly obstinate but it could also mean that they have a considered opinion that it might benefit you to learn.

“More people slow down projects” is an oversimplified version of the premise in The Mythical Man Month. If that simplistic viewpoint held, Google would employ a grand total of maybe a dozen engineers. What The Mythical Man Month says is that more engineers slow down a project that is already behind. i.e. You can’t fix a late project by adding more people.

This does not mean that the amount of code/features/whatever a team can produce or ship is unrelated to the size of the team or the speed at which they can write code. Those are not statements made in the book.

[agentultra]

Sure, I’m not writing a whole critical analysis of TMMM here and am using an aphorism to make a point.

Let’s imagine we’re going to make a new operating system to compete with Linux.

If we have a team of 10 developers we’re probably not going to finish that project in a month.

If we’re going to add 100 developers we’re not going to finish that project in a month.

If we add a thousand developers we’re still not going to finish that project in a month.

But which team should ship first? And keep shipping and release fastest?

My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down.

People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software.

Yet it’s not like adding more code per unit of time is adding anything to the process.

Even adding more people to a factory line had diminishing returns in efficiency.

There’s a sweet spot, I find.

As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like.

As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run.

My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.

[dpark]

> using an aphorism to make a point.

But your “aphorism” is not true. You made a claim that more developers make a project slower. And you pointed to TMMM in support of that claim.

Now you seem to be saying “I know this isn’t really true, but my point hinges on us pretending it is.”

> Let’s imagine we’re going to make a new operating system to compete with Linux.

This is a nonsensical question. “Would you rather be set up to fail with 10 engineers or 1000”? Your proposed scenario is that it’s not possible to succeed there is no choice to be made on technical merit.

> But which team should ship first? And keep shipping and release fastest?

Assuming you are referring to shipping after that initial month where we have failed, the clear option is the largest of the teams. A team of 10 will never replicate the Linux kernel in their lifetimes. The Linux kernel has something like 5000 active contributors.

> I’ve heard stories that it takes a long time to get small changes to production.

There are many reasons it’s slow to ship changes in a company like Google. This doesn’t change the fact that no one is building Chrome or Android with a team of ten.

[bdangubic]

> It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.

This type of comments is all that is wrong with our industry. If "shipping it" is an issue there are a colossal failure throughout the entire organization. My team "shipped" 11 times yesterday, 7 on Monday, 21 on Friday... "shipping" is a non-event if you know what the F you are doing. If you don't, you should learn. If adding more people to help you with the amazing shit you are doing makes you slower, you have a lot of work to do up and down your ladder.

[agentultra]

Maybe it's just my luck but most engineering teams I've worked with that were building some kind of network-facing service in the last 16-some-odd-years have tried to implementing continuous delivery of one kind or another. It usually started off well but it ends up being just as slow as the versioned-release system they used before.

It sounds like your team is the exception? Many folks I talk to have similar stories.

I've worked with teams to build out a well-oiled continuous delivery system. With code reviews, integration gating, feature flags, a blue-green deployment process, and all of the fancy o11y tools... we shipped several times a day. And people were still afraid to ship a critical feature on a Friday in case there had to be a roll-back... still a pain.

And all of that took way more time and effort than writing the code in the first place. You could get a feature done in an afternoon and it would take days to get through the merge queue, get through reviews, make it through the integration pipeline and see the light of production. All GenAI had done there was increase the input volume to the slowest part of the system.

People were still figuring out the best way to use LLM tools at that time though. Maybe there are teams who have figured it out. Or else they just stop caring and don't mind sloppy, slow, bloated software that struggles to keep one nine of availability.

[deadbabe]

When people say code is the bottleneck, they don’t always mean the lack of code: it’s also the accumulation of code, which becomes like plaque clogging your arteries. When you have too many people pumping out too much code, it can be the death of your startup. Startups have failed from writing way too much code.

[bdangubic]

amazing how many comments in these discussion talk about startups as if that is all there's to it, you either are at startup or you are plumber... [mind blown...]

[jordwest]

I've worked in two different types of environments - one where what you said is absolutely true (most of my jobs), and another where it's not true and the quote holds up.

The difference, I think is:

- Code factories where everything is moving fast - there's no time to think about how to simplify a problem, just gotta get it done. These companies tended to hire their way out of slowness, which led to more code, more complexity, and more code needed to deal with and resolve edge cases introduced by the complexity. I can count many times I was handed directives to implement something that I knew was far more complex than it had to be, but because of the pressure to move forward it was virtually impossible to push back. Maybe it's the only way they can make the business case work, but IMO it undoubtedly led to far, far more code than would've been necessary if it were possible to consider problems more carefully and if engineers had more autonomy. In these companies also a lot of time was consumed by meetings trying to "sync up" with the 100 other people moving in one direction.

- Smaller shops, open source projects, or indie development where there isn't a rush to get something out the door. Here, it's possible to think through a problem and come up with a solution that reduces code surface area. This was about solving the largest number of problems with the least amount of complexity. Most of my time at this company was spent thinking through how to solve the problem and considering edge cases and exploratory coding, the actual implementation was really quick to write. It really helped that I had a boss who understood and encouraged this, and we were working on safety critical systems. My boss liked to say "you can't birth a baby in less than 9 months just by adding another woman".

I think most of the difference is in team size. A larger team inherently results in more code to do less, because of the n*(n-1)/2 communication overhead [1].

Recently I learned the Navy SEALs saying "Slow is smooth, smooth is fast" which I feel sums up my experience well.

[1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

[sublinear]

I think your mind might be blown when you discover a third type of environment. It's neither a small shop of yak-shaving idealists, nor a desperate code factory.

The third environment is a large business maintaining services long term. These services do not change in fundamental ways for well over a decade and they make a shit ton of money, yet the requirements never stop changing in subtle ways for the clients. Bugs pop up constantly, but there's more than enough time to fix them the right way as outlined by their contract where expectations have been corrected over the years. There's no choice to do it any other way. The requirements and deadlines are firm. Reliability is the priority.

These are the stable businesses of the broader working world and they're probably what will remain after AI has driven the tech industry into the ground.

[jordwest]

The second environment I was describing fits what you’re describing more than “yak shaving idealists”.

We were working on control systems for large industry that had to work reliably and with minimum intervention. A lot of these systems were being renewed but the plant was often 30+ years old. We were also dealing with quite limited hardware.

[bdangubic]

HN is a tough crowd for comments like these :) The absolute best work in our industry is this but people (especially younger people which is a shame) are chasing FAANGS is shit like that. I have been blessed (also it wasn't by accident but still blessed) to spend a lot of my career in exactly these kinds of places (minus the bugs popping up constantly :) ).

[apsurd]

Even if the entire totem pole of decision makers in a company thinks writing code is the bottleneck doesn't make it true that writing code is the bottleneck.

On the extreme end to prove the point, the suits intentionally abstract out reality into neat forecasts and spreadsheet cells.

It's hard for me to think of something concrete that will convince you. Does code map directly to business outcomes in your experience? Because it's overwhelmingly not even remotely true in my experience.

even just "all lines of code are not created equal" tells me there's no direct correlation with business value.

[ahefner]

But how much time per week does an SWE actually spend writing code?

[bdangubic]

another one, this is 2nd most frequent thing people write here, not sure how to even approach answering :)

so I’ll do what I was thought in first grade to never do and answer a question with a question - how much time per week does a brick layer spend laying bricks? they are looking at these new “robots” laying bricks automatically and talking on BrickLayerNews “man, the brick laying has not been a bottleneck for a long time.”

But to answer your question directly, a lot of time if other people do their job well. Last week I had about 7 hours of meetings, the rest of the time I was coding (so say 35 hours) minus breaks I had to take to stretch and rest my eyes

[paulhebert]

Interesting! I guess it really varies between jobs, roles, and companies.

Thats never been my experience but I have an odd skill set that mixes design and dev.

I’ve always spent a lot of time planning, designing, thinking, etc.

How detailed are the tickets if you spend all your time coding? You never have to think through architecture, follow up on edge cases the ticket writers didn’t anticipate, help coworkers with their tasks, review code, etc.?

[apsurd]

i think this is it. you're a bricklayer. No, the bottleneck for erecting buildings is not bricklaying.

Without taking all the time to write a dissertation to try to convince you, because why; how about we just start with even zoning laws and demographic analysis preclude the laying of the bricks.

is it so unreasonable to think it is not about the laying of the bricks?

[slopinthebag]

I think you comparing software development to brick laying says all anyone needs to hear about your approach to software development.

It's like saying the bottleneck in mathematics is arithmetic.

[bdangubic]

writing software, if you know what you are doing, is very similar to laying bricks. write smallest possible functions that do one thing and do it well and then compose them, like bricks, to make a house (which is what brick layers do).

comments like this come from places where it is more like bunch of chefs in a italian restaurant making spaghetti pasta (code) :)

[slopinthebag]

No, thats a common mechanistic view of building software but it's not really accurate. Unlike with bricks, the way you arrange your components and subcomponents has an effect on the entire system. It's a complex phenomenon.

Of course your view is quite common especially in the managerial class, and often leads to broken software development practices and the idea that you can just increase output by increasing input. One step away from hiring 9 pregnant women to make a baby in a month.

[bdangubic]

boy I am glad I had good fortune in my 30 years hacking to not work with people like you :)

[slopinthebag]

It sounds like you just aren't very good at managing teams of programmers tbh. If your bottleneck is producing code, very rarely does hiring more programmers actually help.

[bdangubic]

this makes just so much sense, I'll manage my programmers to work 37 hours per day, imma try this next week and will let you know how it goes

[slopinthebag]

Try having your programmers work 30 hours a week instead of 40 and measure their output. You might be surprised.

[Jach]

I agree the slogan isn't very true. It's similar to another line of commentary that would suggest soft skills are more important than the hard skills of actually being able to program, i.e. the primary service being paid for.

There is some truth to it, like Brooks' Law (https://en.wikipedia.org/wiki/Brooks's_law) about how adding people to an already late project will just make it later. There are many factors in how long a software engineering task takes beyond pure typing speed, which suggests there are factors beyond code produced per day as well. But some typing has to be done, and some code has to be produced, and those can absolutely be bottlenecks.

Another way of looking at it that I like is Hickey's hierarchy of the problems of programming and their relative costs, from slide 22: https://github.com/matthiasn/talk-transcripts/blob/master/Hi... If you have inherent domain complexity, or a misconception on how to apply programming to a domain, those are 10x worse costs than any day-to-day practice of programming concerns ("the code"), and there's a 10x further reduction for trivialisms like typos.

I think some of it must be cope since so many are in organizations where the more they get promoted the less they program, trending towards (and sometimes reaching) 0. In such an organization sure, code isn't the bottleneck per se, it's a symptom of an underlying cause. The bottleneck would be the bad incentives that get people to schedule incessant unnecessary meetings with as many people as they can to show leadership of stakeholders for promotion doc material, and other questionable things shoved on the best engineers that take them away from engineering. Remove those, and suddenly productivity can go way up, and code produced will go up as well.

I've also always been amused by estimates of what constitutes "good" productivity if you try to quantify it in lines of code. There's a paper from 1994 by Jim Coplien, "Borland Software Craftsmanship: A New Look at Process, Quality, and Productivity". It's summarized in the free book by Richard Gabriel, "Patterns of Software". (https://www.dreamsongs.com/Files/PatternsOfSoftware.pdf pg 135) They were making new spreadsheet software for Windows, and had a group of "very high caliber" professionals, with a core group of 4 people (2 with important prior domain expertise) and then 4 more team members added after a year. "The QPW group, consisting of about eight people, took 31 months to produce a commercial product containing 1 million lines of code. This elapsed time includes the prototypes, but the line count does not. That is, each member of this group produced 1,000 lines of final code per week."

Later on, Coplien was asked "what he thought was a good average for US software productivity", and the answer was "1000 to 2000 non-commentary source lines per programmer per year". Also: "this number was constant for a large in-house program over its 15-year lifetime -- so that original development and maintenance moved at the same pace: slowly". An average of 1k lines a year is 19 lines a week, or about 4 lines a day for a work-week. This was considered acceptable for an average, whereas for an exceptional team you could get 200 a day. Might not there be ways to boost the average from 4 to something like 12 or 20? If your organization is at 4, there is clearly a bottleneck. (For extra context, the QPW group was in C++, and Gabriel notes he had personal experience with several groups demonstrating similar productivity levels. "I watched Lisp programmers produce 1000 lines of Lisp/CLOS code per month per person, which is roughly equivalent to 350 to 1000 lines of C++ code per week." Of course language matters in lines of code comparisons.)