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

271–280 of 299 posts

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

#271

Post by canarias_mate »

bluGill wrote: post #129
judahmeek wrote: post #124

Earlier quoted context omitted.

Something is missing in the common test suite if this can occur, right?

You have to fight to get agents to write tests in my experience. It can be done, but they don't. I've yet to figure out how get any any agent to use TDD - that is write a test and then verify it fails - once in a while I can get it to write one test that way, but it then writes far more code to make it pass than the test justifies and so is still missing coverage of important edge cases.

[flagged]

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

#272

Post by CodeMage »

9rx wrote: post #264
CodeMage wrote: post #258

Earlier quoted context omitted.

> Writing code is just means of conveyance, no? Yes, which is why I have been making the distinction between "programming" and "writing code" all this time. Programming is hard because it's not merely writing code. Determining what to program is not the same as determining what code to write. "What to program" is about requirements. Going from "what to program" to "what code to write" is what programming is about.

> Going from "what to program" to "what code to write" is what programming is about. Once your requirements are established there isn't any thing left to choose from, other than maybe whether to use a while loop instead of a for loop — stuff that makes absolutely no difference. The structure of your code, the algorithms you choose, etc. are all dictated by the requirements. So what lies in this nebulous in-between st…

> The structure of your code, the algorithms you choose, etc. are all dictated by the requirements.

Only if you expand the meaning of the word "requirements" to encompass a full specification of the solution.

> Is it choosing between for and while what you think is hard?

You want to know what I think? I think this conversation is crossing into rudeness.

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

#273

Post by phpnode »

mrsilencedogood wrote: post #171
pphysch wrote: post #156

Earlier quoted context omitted.

A sufficiently complete spec is indistinguishable from source code.

And sometimes it can't even handle it then. I was recently porting ruby web code to python. Agents were simultaneously surprisingly good (converting ActiveRecord to sqlalchemy ORM) and shockingly, incapably bad. For example, ruby uses blocks a lot. Ruby blocks are curious little thingies because they are arguably just syntax sugar for a HOF, but man it's great syntax sugar. Python then has "yield" which is simultaneo…

The trick is to generate a spec from the old code, then generate the new codebase from the spec.

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

#274

Post by shiroiuma »

siliconc0w wrote: post #185
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…

+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…

>Google's infrastructure is, IMO, a competitive advantage. The amount of vertical integration and scale is unparalleled.

It's too bad they don't put this kind of thinking into their customer service.

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

#275

Post by shiroiuma »

shimman wrote: post #197
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…

Incentive of undemocratic groups is to build mini-empires yes, but if the business decisions were led by workers instead of a group of tyrants it'll most likely be a better decision. If we want lived examples of this, look at recorded history.

>if the business decisions were led by workers instead of a group of tyrants it'll most likely be a better decision.

I don't see how. The workers will want to work on things that they enjoy, or that make them look good, regardless of how much they help the company's bottom line. Why would workers not want to build mini-empires of their own? If you're thinking that other workers in the company would vote them down, the problem with this is idea is that other workers in the company won't know about or understand why this time-wasting group is doing what it's doing, because it's not part of their competency. Do you keep track of business decisions and happenings in some other group in your company (assuming you're in a large organization)? Of course not; you don't have time to keep track of everything happening across the organization. So why would workers in your worker-led company do any better?

The entire point of leadership is that individuals don't have the time or expertise to know all this stuff and make smart decisions.

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

#276

Post by satvikpendem »

llmssuck wrote: post #238
simonw wrote: post #229

Earlier quoted context omitted.

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.

Well yes, those are all programming, just as there are many different types of engineering, civil, mechanical, nuclear etc.

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

#277

Post by cruffle_duffle »

skrebbel wrote: post #152
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 art is load-bearing This is beautiful

Oh my god have Anthropic products been absolutely saying everything is load bearing for the last week or so. Literally ever other paragraph has “such and such is load-bearing”.

Funny enough, today it seems to have stopped…

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

#278

Post by shiroiuma »

RALaBarge wrote: post #104
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…

The more I work with AIs (I build AI harnessing tools), the more I see similarities between the common attention failures that humans make. I forgot this one thing and it fucks everything up, or you just told me but I have too much in my mind as context that I forget that piece, or even in the case of Claude last night attesting to me while I am ordering it around that it cannot SSH into another server but I find it…

>...I see similarities between the common attention failures that humans make. I forgot this one thing and it fucks everything up, or you just told me but I have too much in my mind as context that I forget that piece

Or you're working in a trendy, modern open-plan office and between the noise from the salespeople nearby talking loudly to customers on their speakerphones, some coworkers talking about their medical issues, and the guy right next to you talking loudly to himself in a different language, you're unable to concentrate at all on your programming task.

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

#279

Post by 9rx »

CodeMage wrote: post #272
9rx wrote: post #264

Earlier quoted context omitted.

> Going from "what to program" to "what code to write" is what programming is about. Once your requirements are established there isn't any thing left to choose from, other than maybe whether to use a while loop instead of a for loop — stuff that makes absolutely no difference. The structure of your code, the algorithms you choose, etc. are all dictated by the requirements. So what lies in this nebulous in-between st…

> The structure of your code, the algorithms you choose, etc. are all dictated by the requirements. Only if you expand the meaning of the word "requirements" to encompass a full specification of the solution. > Is it choosing between for and while what you think is hard? You want to know what I think? I think this conversation is crossing into rudeness.

> Only if you expand the meaning of the word "requirements" to encompass a full specification of the solution.

They are one in the same, no? Why would one write code that isn't required?

Are you referring to the aforementioned iteration process where the act of writing code and measuring the results will lead to realizing that not all requirements have been gathered? When you start with bubble sort and then users complain that your program is too slow you will realize that you missed that efficiency as a requirement when you were first determining "what to write", sure, but theoretically the requirement was there all along. I don't think when you discover "what to write" really matters with respect to the discussion. The process was understood in the original comment.

We can recognize that transient state where one hypothetically thought bubble sort was a suitable algorithm for the user's requirements when it actually wasn't. But isn't it still chosen under some misaligned understanding of the user requirements, like seeing bubble sort as being quick to implement and thinking fastest delivery is the requirement in the moment? The choice to use bubble sort is not random. I'm not sure refinement as more information becomes available changes anything.

> You want to know what I think? I think this conversation is crossing into rudeness.

True. I can think of nothing more rude than asking for clarification an in effort to understand someone. My apologies. I will only talk past you henceforth... But seriously, appeal to emotion is a poor device. There is no good faith discussion that can venture into the world of logical fallacies. What were you trying to accomplish here?

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

#280

Post by 9rx »

krackers wrote: post #261
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…

If good writing was easy then "LLM slop writing" wouldn't be a thing.

Not at all. LLM slop exists exactly because writing is easy, but figuring out what to write is hard.
Post reply on HN