Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

viktorcessan.com

Post reply on HN
Print view View original

241–250 of 299 posts

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

#241

Post by jjk7 »

pphysch wrote: post #157
rpdillon wrote: post #117

Earlier quoted context omitted.

Right, but when humans are writing the code, they have learned to focus on putting downward pressure on the complexity of the system to help mitigate this effect. I don't get the sense that agents have gotten there yet.

Big business LLMs even have the opposite incentive, to churn as many tokens as possible.

At least tokens are equivalent to measuring 'thinking'... I wouldn't mind if it burned 100k tokens to output a one line change to fix a bug.

The problem is maximizing code generated per token spent. This model of "efficiency" is fundamentally broken.

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

#242

Post by siliconc0w »

Aurornis wrote: post #203
siliconc0w wrote: post #185

Earlier quoted context omitted.

+1 A huge amount of software - probably most - is not actually generating value and in many cases is actually reducing value. I've seen teams build and re-build the same infrastructure over and over. I saw a request that could have been met with a few SQL queries and a dashboard got turned into a huge endeavor that implements parts of an ETL, Configuration Management, CI/CD, and Ticketing system and is now in the cri…

One of the most confusing moments in my early career was when someone spent two whole quarters building a custom tool that did something a mature and well respected open source project did for us. There was no advantage to his tool and he would admit it when cornered by the question. We all thought he would get reprimanded for wasting so much time, but by the time management figured out was happening they decided the…

I heard a CEO try to sell some tech they had as this hugely valuable IP and a competitive moat.

When I asked the team that is supposed to use it, "We haven't used that in six months and it wouldn't be missed if it were to go away".

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

#243

Post by llmssuck »

Loic wrote: post #235
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 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 t…

I suppose the complexity of the domain is the main driver of the difficulty level. Perhaps that's the intuition that I'm trying to pin down: programming itself, the typing of words for the compiler, the act of converting pure thought into code, seems mechanical at best. But if you include the act of abstraction itself, then I concede it changes the equation. I don't find it to be all that clear what is and isn't programming to be honest.

Especially once you get to describe your abstractions in plain (or slightly technical) English instead of code I find it hard to say "programming" is being performed, but in many ways the case could be made that it remained the same and only the shape of the artifacts is different now.

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

#244

Post by Dr4k3_ »

“Day 14: A functional replica of Slack’s core product, built by Nathan using LLM agents.” What does that even mean? What are “core features”? Just a chat room? That’s trivial compared to what a real system like Slack actually does: handling millions of messages at scale, ensuring consistency across clients, maintaining high availability, storing and serving media (videos, audio, images), managing backups, and more. Building a simple chat app that mimics Slack’s UI isn’t impressive. That was a few hours of work even 20 years ago, long before LLMs. Calling that a “replica of Slack’s core product” is, at best, misleading.

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

#245

Post by red-iron-pine »

bdunks wrote: post #105

> Software development is one of the most capital-intensive activities a modern company undertakes The article is definitely written from a "high tech" industry lens. A mid-sized utility might spend $80-$150 million USD on IT capital projects in a year, but $2b on power pole maintenance. Utilities are a strong example, but any large enterprise manufacturing company is spending more on factory upgrades that programmin…

the SaaS isn't going anywhere. you're going to AI yourself a Tier 4 data center and all of the requisite generators and UPS systems.

And how do you put liability on an LLM agent? I outsource to SaaS and consultants because 1) they're good at what they do, and 2) if they do it wrong I can sue them, escalate, berate them in social media, etc. and get things fixed; the AI pulls from so many places who is responsible? How do I validate that?

I blackbox that I can't audit is a lot of risk compared to expensive consultants with shortcomings.

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

#246

Post by 9rx »

CodeMage wrote: post #222
9rx wrote: post #213

Earlier quoted context omitted.

> That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school". Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself? > there are many different ways to write a program to satisfy them. "What to program" being hard was accepted…

> Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself? Being able to transcribe sentences in a certain language is the skill kids pick up in elementary schools. Being a writer requires a whole set of skills built on top of that. The reason why I brought up that difference in the…

> Writing code that solves your users' requirements is "programming".

For me, I need to have a solution figured out before writing code. I am not even sure how you could write code before having the problem solved. Your approach would be insightful.

Like, I get it is effectively impossible to gather all user requirements upfront and that you need to build a product to find out what details you overlooked. That means software is an iterative process. But within each iteration, surely you still need to have the solution — to the extent that it satisfies the known requirements — prepared before you can write code? Maybe if you had an infinite number of monkeys you could have them bang out something that accidentally works by throwing down random keywords, but in the real world where it is only you and your code has to meaningful, what you program is simply the expression of what to program.

Writing code is just means of conveyance, no?

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

#247

Post by strife25 »

I like this angle. I didn't read much of the article, but I do think this is a topic that people should consider, at least when it comes to estimating software projects. I don't think we really think enough about the monetary costs of our projects. When I raise the topic in my discussions, it really changes and focuses people, particularly when folks are advocating for tech debt projects that don't really have a return because they're not a focus for the company at this time. When we say that it's going to be a $60,000 project, it quickly becomes deprioritized in the conversation.

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

#248

Post by 9rx »

ozim wrote: post #234
9rx wrote: post #205

Earlier quoted context omitted.

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.

Absolutely. I am quite capable of moving the pieces around a chess board within the confines of the rules. I think you would be hard-pressed to find many who are incapable of that, given exposure to the game. If that isn't easy, what is? I am not all that good at figuring out what moves to make, but that analogs with "what to program", not "programming" as it pertains to the discussion that has been talking place. Nobody has ever suggested "what to program" is easy.

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

#249

Post by socalgal2 »

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…

> . This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed.

LLMs make this trivial. I can try 20 different approaches or design ideas in a day. VS manually doing it and it taking much longer.

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

#250

Post by yibg »

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.

Probably difference in the boundary of what programming entails too. Eg is coming up with the algo itself part of programming or only the writing the implementation part after the algo is clear.

The first is hard, the second much less so.

Post reply on HN