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

261–270 of 299 posts

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

#261

Post by krackers »

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

Earlier quoted context omitted.

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard? That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school". Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bu…

> 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.

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

#262

Post by boron1006 »

jwpapi wrote: post #73
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…

Same here. I have now deleted 43k and counting lines of my codebase. There is no point in putting any AI code into production anymore as it almost always uses none or the wrong abstractions. When you try to throw more agents at the problem or even more verification layer, you just kill your agility even if they would still be able to work

Case in point, just this morning I contributed a one-line change to an open source repo and the CI started failing.

I asked Claude (Opus High Effort) and pasted in all the logs. I went back and forth and it very confidently made over 20 separate changes in the repo, none of which fixed the issue. Eventually I stepped in and figured out it was a versioning issue.

I fear what would happen if I ran “10 agents for 10 days” on this simple issue.

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

#263

Post by ozim »

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

Earlier quoted context omitted.

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. No…

You missed the point.

At some level even if you know basic moves those moves are wrong.

Some things are hard to express in code even if you know exactly what you need to achieve and you know all the basic moves like loops and if statements.

If you know that you have to do a check mate or get amount of points and you know how to do basic moves but you don’t know any openings you are going to loose in 3-5 moves. If you get past openings you might get to 15 moves. If you do easiest greedy approach you loose if you take easiest defensive approach you loose.

It is not „what to program” because in chess you exactly know what is the goal. Getting to that goal alone is hard.

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

#264

Post by 9rx »

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

Earlier quoted context omitted.

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

> 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 state and what makes it so hard? Is it choosing between for and while what you think is hard?

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

#265

Post by 9rx »

ozim wrote: post #263
9rx wrote: post #248

Earlier quoted context omitted.

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. No…

You missed the point. At some level even if you know basic moves those moves are wrong. Some things are hard to express in code even if you know exactly what you need to achieve and you know all the basic moves like loops and if statements. If you know that you have to do a check mate or get amount of points and you know how to do basic moves but you don’t know any openings you are going to loose in 3-5 moves. If you…

> Some things are hard to express in code even if you know exactly what you need to achieve and you know all the basic moves like loops and if statements.

Like what? Are you, perhaps, confusing "hard" with "time consuming"? Some things take a long time to express in code (absent AI, at least). It's not hard, though. It's just rote copying down what you have already determined "what needs to be programmed". Getting to the point where it is just rote copying can be difficult, but is decidedly in the "what to program" phase.

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

#266

Post by johnnyanmac »

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…

>Some times the programming part really is very hard even when it’s easy to know what needs to be built

Sometimes. Most programming jobs out there just need a button on a website or a 2 line fix for some off-by-1 error, though. Those who are working on novel, cutting edge problems are relatively rare.

As you said, most software enginering is connecting existing frameworks together and being in meetings on how/when best to do it. Not necessarily a bad thing at all, but that's why the metaphor of the mechanic or doctor works out here, where the labor to know where and how to fix something is worth much more than the actual part (or medicine's) cost.

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

#267

Post by johnnyanmac »

ravenstine wrote: post #206
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…

Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built. The saying also ignores the fact that humans are not perfect programmers, and they all vary in skills and motives. Being a programmer often not about simply writing new code but modifying existing code, and that can be incredibly challenging when that code is hairbrained or overly…

I imagine the hard part isn't the literal building of the stuff. It's the months or years of politics, beauracracy, and bids needed to get to a point where you can build it.

That's not to discount the intensity of the labor. Just that the labor is rarely the bottleneck in building stuff.

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

#268

Post by johnnyanmac »

CodeMage wrote: post #184
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…

> 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 .

It's all relative. The general idea of this is that a software engineer spent years studying such concepts and then years more working in legacy code.

so it's second nature to do the mechanical operation of "extend a new class from Widget and add a function that returns the number of pencils pushed", and then somewhat easy after a few years to "pipe the pencil pushing function into the website frontend to display". Even if just describing this to a non SWE would have their eyes glaze over, and a junior SWE would struggle getting things integrated.

The painter metaphor works well here:

>Picasso in a restaurant, asked him to scribble something on a napkin, and said she would be happy to pay whatever he felt it was worth. Picasso complied and then said, “That will be $10,000.”

>“But you did that in thirty seconds,” the astonished woman replied.

>“No,” Picasso said. “It has taken me forty years to do that.”

(Disclaimer: I do not think Picasso literally said this, but it's a very common tale)

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

#269

Post by rstuart4133 »

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.

It's true that we often split software engineering into two pieces: doing the design and implementing the code. In fact I often prefer to think of it as computer systems engineering because the design phase often goes well beyond software. You have to think about what networks are used, what the hardware form factor should be used, even how many check digits should be put on a barcode.

But then you go onto say this:

> 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.

That implies LLMs can't help with design of something that needs voice recognition and missile guidance systems. If that's your claim, it's wrong. In fact they are far better at being sounding boards and search engines than they are at coding. They make the same large number of mistakes in design tasks as they do in software coding, but in design tasks the human is constantly in the loop, examining all of the LLM's output so the errors don't matter so much. In vibe coding the human removes themselves from the loop to a large extent. The errors become shipped bugs.

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

#270

Post by canarias_mate »

chaboud wrote: post #93
virgilp wrote: post #60

Earlier quoted context omitted.

qa has long ago merged with programming in "unified engineering". Also with SRE ("devops") and now the trend is to merge with CSE and product management too ("product mindset", forward-deployed engineers). So yeah, pretty much, that's the trend. What would you trust more - an engineer doing project management too - or a project manager doing the engineering job?

From my experience with modern software and services, the actual practice of QA has plainly atrophied. In my first gig (~30 years ago), QA could hold up a release even if our CTO and President were breathing down their necks, and every SDE bug-hunted hard throughout the programs. Now QA (if they even exist) are forced to punt thousands of issues and live with inertial debt. Devs are hostile to QA and reject responsib…

[flagged]
Post reply on HN