The economics of software teams: Why most engineering orgs are flying blind • Hacker News Board

Re: The economics of software teams: Why most engineering orgs are flying blind

#231

Post by wmwragg » Mon, Apr 13, 2026, 7:43 PM UTC

Aurornis wrote: post #201

rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism because I’ve been in enough situations where it was not true. Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole…

Yep, I think people who repeat this aphorism essentially equate programming with typing, or as you say just connecting existing bits together. Programming is the working out how to get a computer to perform some task, not just the typing, it's the algorithms, the performance balancing, the structuring, the integration etc.

Re: The economics of software teams: Why most engineering orgs are flying blind

#232

Post by cyanydeez » Mon, Apr 13, 2026, 7:55 PM UTC

jimbokun wrote: post #180

cyanydeez wrote: post #106

Earlier quoted context omitted.

I think you missed the key capitalist part: There needs to be someone to benefit from all your labor. No, no, it can't be you. You have conflicts of interest!

What if your work isn't benefitting anyone?

If it sells, you don't own it! No one said a product needs to benefit people.

Re: The economics of software teams: Why most engineering orgs are flying blind

#233

Post by pydry » Mon, Apr 13, 2026, 8:12 PM UTC

wmwragg wrote: post #231

Aurornis wrote: post #201

Earlier quoted context omitted.

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism because I’ve been in enough situations where it was not true. Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole…

Yep, I think people who repeat this aphorism essentially equate programming with typing, or as you say just connecting existing bits together. Programming is the working out how to get a computer to perform some task, not just the typing, it's the algorithms, the performance balancing, the structuring, the integration etc.

Or theyre just picturing some CRUD app that needs to connect to a few APIs being made for a clueless exec who doesnt even understand their own business problem.

To be fair, a lot of programming does end up being just that.

Re: The economics of software teams: Why most engineering orgs are flying blind

#234

Post by ozim » Mon, Apr 13, 2026, 8:19 PM UTC

9rx wrote: post #205

CodeMage wrote: post #184

Earlier quoted context omitted.

> the actual programming is not the hard part We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard .

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? Determining what to program can be hard, but that was already considered earlier. The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programm…

You sound like you would confidently say that you can play chess. Basic moves are easy to learn by very young children.

But if only thing you know are basic moves playing against a player with 1600 ELO you are not going to win without serious training and 1600 is still far below grand master level.

Re: The economics of software teams: Why most engineering orgs are flying blind

#235

Post by Loic » Mon, Apr 13, 2026, 8:20 PM UTC

llmssuck wrote: post #224

Aurornis wrote: post #201

Earlier quoted context omitted.

> which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. I’m growing tired of this aphorism because I’ve been in enough situations where it was not true. Some times the programming part really is very hard even when it’s easy to know what needs to be built. I’ve worked on some projects where the business proposition was conceptually simple but the whole…

> it was an extremely hard engineering problem But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or…

I am spending about 10h per day solving chemical engineering problems (dynamic simulation, model predictive control, etc.). The programming is hard on top of hard science. Even after 25 years of experience, it is still hard to find the right abstraction to implement everything.

Still, one thing I really like with LLM/AI, is that now, I can allow myself to test different abstractions a bit faster. I can allow myself to "try" more complex refactoring on a feature branch, because if I describe correctly the abstraction I want, the LLM/AI tool will be normally good at producing it. But to describe my abstraction, I need to pull all my programming and engineering years of experience.

But at the end of the day, I always tell my wife, that with these new tools, which I could not imagine so powerful 3 years ago, I live in the future :-)

Re: The economics of software teams: Why most engineering orgs are flying blind

#236

Post by zingar » Mon, Apr 13, 2026, 8:20 PM UTC

boron1006 wrote: post #18

> A messy codebase is still cheaper to send ten agents through than to staff a team around. And even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today. I’ve been on 2 failed projects that have been entirely AI generated and it’s not that agents slow down and you can just send more agents to work on projects for longer, it’s…

Any chance of a blog post covering what you saw?

Re: The economics of software teams: Why most engineering orgs are flying blind

#237

Post by jjk7 » Mon, Apr 13, 2026, 8:20 PM UTC

cyanydeez wrote: post #109

pron wrote: post #95

> A messy codebase is still cheaper to send ten agents through than to staff a team around People who say that haven't used today's agents enough or haven't looked closely at what they produce. The code they write isn't messy at all. It's more like asking the agent to build a building from floorplans and spec, and it produces everything in the right measurements and right colours and passes all tests. Except then you…

The problem is, the MBAs running the ship are convinced AI will solve all that with more datacenters. The fact that they talk about gigawatts of compute tells you how delusional they are. Further, the collateral damage this delusion will occur as these models sigmoid their way into agents, and harnesses and expert models and fine tuned derivatives, and cascading manifold intelligent word salad excercises shouldn't be…

Why worry?

Re: The economics of software teams: Why most engineering orgs are flying blind

#238

Post by llmssuck » Mon, Apr 13, 2026, 8:21 PM UTC

simonw wrote: post #229

llmssuck wrote: post #224

Earlier quoted context omitted.

> it was an extremely hard engineering problem But that is not programming then? Doing voice recognition in the 90s, missile guidance systems, you name it, those are hard things, but it's not the "programming" that's hard. It's the figuring out how to do it. The algorithms, the strategy, etc. I might be misunderstanding, but I cannot see how programming itself can be challenging in any way. It's not trivial per se or…

I count "figuring out how to do it" as part of the work of programming, personally.

Fair enough, but I think that never really worked all that well. What I mean is that the term "programming" would then essentially cover anything and everything that can be put into an algorithm of some sort. Neutrino detection, user management dashboards, CRUD APIs, basically everything is programming.

It would explain a lot of misunderstanding between "programmers" though.

Re: The economics of software teams: Why most engineering orgs are flying blind

#239

Post by manquer » Mon, Apr 13, 2026, 8:21 PM UTC

9rx wrote: post #205

CodeMage wrote: post #184

Earlier quoted context omitted.

> the actual programming is not the hard part We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard .

What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? Determining what to program can be hard, but that was already considered earlier. The only other place where I sometimes see it become hard for some people is where they treat programming as an art and are always going down crazy rabbit holes to chase their artistic vision. Although I would say that isn't so much that programm…

> Young children seem to pick it up with ease. It cannot be that hard

It is other way around. Children can pick up a lot of skills that adults struggle at, like languages for example.

Plenty of research has shown reduced plasticity of the brain has stronger correlation to learning speed and ability as it grows old. Most breakthrough research is usually at age 40 or less or chess grand-masters fade in skill after. 25-40 is probably age group where the optimal balance between knowledge experience and learning ability for best outcomes.

Re: The economics of software teams: Why most engineering orgs are flying blind

#240

Post by nonameiguess » Mon, Apr 13, 2026, 8:24 PM UTC

juancn wrote: post #208

The over-simplification rubs me the wrong way, for example: Consider a team of eight engineers whose mission is to build and maintain an internal developer platform serving one hundred other engineers. This is a common organizational structure, and it is one where the financial logic is rarely examined carefully. The team costs €87,000 per month. To justify that cost, the platform they build needs to generate at leas…

It's missing the point of a platform team. Regardless of how you choose to organize your larger business, each individual product needs similar things. Whatever those may be. Code forge. Binary artifact repositories. Build, test, and deployment pipelines. Development and staging environments. Workstations with a network connection to your business systems. You can do pay for SaaS enterprise stuff, build it yourself team by team, or have a platform team. The point at which it makes economic sense to have a platform team isn't when they can directly save money by saving time. It's when you have enough product teams that having them all devote effort to doing the same thing in parallel when it can be centralized is counterproductive, and your needs are sufficiently niche or the seat licensing is high enough that SaaS solutions no longer work, either.

It's effectively a form of administrative overhead. The question isn't whether the cost is justified. You have to do it. The question is whether you're better off centralizing the function in house or not. You see a similar dynamic with any other administrative function. Should you hire a payroll company or have your own payroll department? The difference is software developers tend to believe, and in many cases might even be right, that they can individually role their own platform functions, introducing a secondary consideration, whereas the idea of having software developers simply handling their own payroll clearly makes no sense.

Of course, it's worth another of the more obvious reasons it doesn't make sense. If you give your engineers direct access to the company bank account, there's a pretty clear risk they're going to steal from you. Similarly, there's a non-economic argument to be made for having a platform team in terms of separation of duties for security. Every business decision isn't simply made by answering what does this cost and how much will it earn me? Try running a software business where the developers are responsible for physical site security and see how long you make it before getting robbed. Try not hiring any janitors, letting your developers clean their own restrooms, and see how long you retain any staff.