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

51–60 of 299 posts

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

#51

Post by tonyedgecombe »

Cthulhu_ wrote: post #26
iamflimflam1 wrote: post #21

Earlier quoted context omitted.

Very much like humans when they drown in technical debt. I think the idea that a messy codebase can be magically fixed is laughable. What I might believe though is that agents might make rewrites a lot more easy. “Now we know what we were trying to build - let’s do it properly this time!”

Potentially, yes, but as with other software, you need to know AND have (automated) verifications on what it does, exactly. And of course, make the case that it actually needs a rewrite, instead of maintenance. See also second-system effect.

>And of course, make the case that it actually needs a rewrite, instead of maintenance.

"The AI said so ..."

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

#54

Post by mlazos »

Look! A guy built 95% of slack in 2 weeks! Very skeptical of that btw, but also an organization that justifies every single team by exactly how much $ value they’re generating sounds like hell. How would you ever innovate or try out new ideas? It’s important to quantify what impact your team is generating but there are some cases (e.g. UX) which are really hard to quantify in $ but are still very important for the product

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

#55

Post by tome »

jillesvangurp wrote: post #43

If you want to understand economics, I recommend watching some of Don Reinertsen's videos on Lean 2.0. He goes into a few concepts quite deeply that are quite intuitive. Cost of delay: calculating the cost of delaying by a few weeks in terms of lost revenue (you aren't shipping whatever it is you are building), total life value of the product (your feature won't be delivering value forever), extra cost in staffing. Y…

Do you have any recommendations? I find his book Principles of Product Development Flow very interesting.

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

#56

Post by ben_w »

bonesss wrote: post #25
leokennis wrote: post #3

> The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. That is a reasonable concern, but it largely applies when agents produce code that humans then maintain. Agentic platforms are being iterated upon quickly, and for established patterns and non-business-critical code, which is the majority of what most engineering organizations actually maintain, detailed human fam…

Ceding the premise that the AGI is gonna eat my job, my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue. There are five layers of fluffy management and corporate BS before we get to that part, and the AGI is more competent at those fungible skills. With the annoying process people out of the picture, even reviewing vibeslop full time sounds kinda nice… Feet u…

> my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue.

So, you're the programmer (verify code) and the QA (verify output) and the project manager (read the spec)?

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

#57

Post by tsukikage »

bonesss wrote: post #25
leokennis wrote: post #3

> The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. That is a reasonable concern, but it largely applies when agents produce code that humans then maintain. Agentic platforms are being iterated upon quickly, and for established patterns and non-business-critical code, which is the majority of what most engineering organizations actually maintain, detailed human fam…

Ceding the premise that the AGI is gonna eat my job, my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue. There are five layers of fluffy management and corporate BS before we get to that part, and the AGI is more competent at those fungible skills. With the annoying process people out of the picture, even reviewing vibeslop full time sounds kinda nice… Feet u…

https://de.wikipedia.org/wiki/Sitzredakteur

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

#58

Post by willvarfar »

With a long time in the industry and seeing how so many big software companies work, this really really chimed with me. Many/most teams and projects and busy work are not actually moving the bottom line, at massive opportunity cost! And there's so little awareness that most people in squads and their managers will think they are the exception.

Whereas Whatsapp with its 30 software engineers was the exception etc.

A chat with friends showed how there are parallels with how LLMs will happen in the short-term future - say the next 5 years - and the whole MapReduce mess. Back when Hadoop came along you built operators and these operators communicated through disk. It took years even after Spark was about for the hadoop userbase as a whole to realise that it is orders of magnitude more efficient to only communicate through disk when two operators are not colocatable on the same machine and that most operators in most pipelines can be fused together.

So for a while LLMs will be in the Hadoop phase where they are acting like junior devs and making more islands that communicate in bigger bloated codebases and then there might be a realisation in about 2030 that actually the LLMs could have been used to clean up and streamline and fuse software and approach the Whatsapp style of business impact.

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

#59

Post by ben_w »

Cthulhu_ wrote: post #26
iamflimflam1 wrote: post #21

Earlier quoted context omitted.

Very much like humans when they drown in technical debt. I think the idea that a messy codebase can be magically fixed is laughable. What I might believe though is that agents might make rewrites a lot more easy. “Now we know what we were trying to build - let’s do it properly this time!”

Potentially, yes, but as with other software, you need to know AND have (automated) verifications on what it does, exactly. And of course, make the case that it actually needs a rewrite, instead of maintenance. See also second-system effect.

> Potentially, yes, but as with other software, you need to know AND have (automated) verifications on what it does, exactly.

Yes, but even here one needs some oversight.

My experiments with Codex (on Extra High, even) was that a non-zero percentage of the "tests" involved opening the source code (not running it, opening it) and regexing for a bunch of substrings.

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

#60

Post by virgilp »

ben_w wrote: post #56
bonesss wrote: post #25

Earlier quoted context omitted.

Ceding the premise that the AGI is gonna eat my job, my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue. There are five layers of fluffy management and corporate BS before we get to that part, and the AGI is more competent at those fungible skills. With the annoying process people out of the picture, even reviewing vibeslop full time sounds kinda nice… Feet u…

> my job involves reading the spec to be able verify the code and output so the there’s a human to fire and sue. So, you're the programmer (verify code) and the QA (verify output) and the project manager (read the spec)?

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?
Post reply on HN