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

221–230 of 299 posts

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

#221

Post by chermi »

chermi wrote: post #153
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…

This just sounds like incomplete specs to me. And poor testing.

Lol I largely agree with my beloved dissenters, just not on the same magnitude. I understand complete specs are impossible and equivalent to source code via declaration. My disagreement is with this particular part:

"t'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 find out that the walls and beams are made of foam and the art is load-bearing. "

If your test/design of a BUILDING doesn't include at simulations/approximations of such easy to catch structural flaws, its just bad engineering. Which rhymes a lot with the people that hate AI. By and large, they just don't use it well.

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

#222

Post by CodeMage »

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…

> 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 first place is because both of these are called "writing". When a fan says "I heard the author is writing the next book in the series" or when an author says "I haven't been able to focus on writing due to my health issues", they're not talking about the low-level transcription skill.

> "What to program" being hard was accepted from the onset and so far we see no disagreement with that.

Similar to your interpretation of "writing", you're choosing to interpret "programming" as a process of transcribing an algorithm into a certain programming language, and everything else ends up being defined as "what to program".

That's an overly reductive interpretation, given the original context:

> For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to find out what programming actually needs to be done, is to program something that's not it, and then replace it. 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.

> [...]

> Most of what is being done, during programming, is working through the problem space in a way which will make it more obvious what your mistakes are, in your understanding of the problem and what a solution would look like.

Notice that the original comment talks defines "determining what to program" as a process of refining your understanding of the problem itself.

In my reading of the original comment, understanding what your users need is "what to program". Writing code that solves your users' requirements is "programming".

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

#223

Post by balderdash »

i think the thing that hits home for me here is that when you go back and do the after action report on where the time was spent last year and what it cost its terrifying. of course hindsight is 20/20 and predicting how difficult something is going to be is hard, but when you say we spent $x million on this version update that does y and $a hundred thousand to implement this feature - you think to yourself we would have never made that cost / benefit decision if we had known.

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

#224

Post by llmssuck »

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…

> 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 quickly over, but I fail to see how it can be anything but mechanical in and of itself. This feels like "writing" as in grammar and typing is the hard part of writing a book.

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

#225

Post by anyonecancode »

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…

> Imagine telling workers at a construction company that the hard problem was never building stuff but figuring out what needs to be built.

Isn't this kind of true, though? Housing construction, for instance, isn't bottlenecked by the technical difficulties of building, but by political and regulatory hurdles. Or look at large, capital-intensive projects such as the always-proposed, never built new Hudson river train tubes. Actually building these will take billions of dollars and many years, but even they would be long built by now were it not for their constantly being blocked by political jockeying.

Building stuff _does_ often involve difficult technical challenges, but I still think that as a general aphorism the observation that this isn't the _hardest_ part holds true.

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

#226

Post by llmssuck »

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…

We might have different concepts of "hard", but if I were a construction worker I think I would agree. Hell, I'm a developer and I agree. Figuring out what to do definitely is the hard part. The rest is work and can be sweaty, but it's not hard as if it's full of impenetrable math or requiring undiscovered physics. It's just time-consuming and in the case of construction work physically tiring.

It might be that I have been doing this for too long and no longer see it.

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

#228

Post by groundzeros2015 »

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…

For whatever reason 1/10 engineers seem to be able to bring an idea from start to finish by themselves. I don’t know that it’s technical skill, but something difficult is going on there.

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

#229

Post by simonw »

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 count "figuring out how to do it" as part of the work of programming, personally.

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

#230

Post by kaffekaka »

bitwize wrote: post #160
ThunderSizzle wrote: post #86

Earlier quoted context omitted.

That's the difference between programming and software engineering. A software engineer should be able to talk directly to customers to capture requirements, turn that into spec sheet, create an estimate and a bunch of work items, write the whole system (or involve other developers/engineers/programmers to woek on their work items), and finally be able to verify and test the whole system. That entire role is software…

Careful with that though. The guy whose entire job is to "take requirements from the customers and bring them to the engineers" really does get awful tetchy if the engineers start presuming to fill his role. Ask me how I know.

Please tell more.

I have the same impression. But that is where it is going - roles merging and being able to do the full spectrum will be valuable.

Post reply on HN