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

121–130 of 299 posts

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

#121

Post by skydhash »

philk10 wrote: post #114
chaboud wrote: post #93

Earlier quoted context omitted.

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…

that's not the role of QA to be a gatekeeper, they give the CTO and President information on the bugs and testing but it's a business decision to ship or not

I’m not a native English speaker, but isn’t gatekeeping exactly that? Blocking suspicious entities unless they’re allowed through by someone higher in the hierarchy?

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

#122

Post by visiohex »

The core reason most orgs are "flying blind" is that we still don't have a reliable metric for technical debt. Management only tracks shipped features and velocity because they are easy to measure. They completely ignore the hidden liability of a rushed, messy codebase until productivity eventually grinds to a halt. You can't measure the economics of a team if you ignore the balance sheet.

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

#123

Post by cmiles74 »

There's a lot here, mixed some marketing and some dubious LLM claims. That being said, I think there could be real benefit in pushing detail on how features effect finances down to individual teams. Right now I have two features on my desk that both seem reasonable; if I knew which one would generate more income (i.e. increase customer retention, lead to more sales, etc.) that would make this choice a lot easier.

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

#124

Post by judahmeek »

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…

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

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

#125

Post by esafak »

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…

Agents run fast. Not always in the right direction. They benefit from a steady hand.

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

#126

Post by pron »

judahmeek wrote: post #124
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…

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

First, it's not "can occur" but does occur 100% of the time. Second, sure, it does mean something is missing, but how do you test for "this codebase can withstand at least two years of evolution"?

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

#127

Post by j16sdiz »

iamflimflam1 wrote: post #21
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…

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!”

It will make rewrite quicker, not "easier".

When the management recognize a tech debt, often it is too late that nobody understand the full requirement or know how things are supposed to work.

The AI agent will just make the same mistake human would make -- writing some half ass code that almost work but missing all sorts of edge case.

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

#128

Post by tom_ »

anonymous908213 wrote: post #29
lynx97 wrote: post #19

Earlier quoted context omitted.

I know it’s an idiom. The point is that it still uses blindness as a stand-in for incompetence/unsafe guessing . Being common doesn’t make it harmless. Common just means we’ve normalized it. And you defending it shows that weve normalized it to a point where the double-meaning is seemingly only apparent to blind people.

It absolutely does not use blindness as a stand-in for incompetence, that is your own outrage-seeking interpretation of it. A neutral interpretation would be that "flying blind" is to "operate without perfect information". It is a simple description of operating conditions, not a derogatory term in any way. Your reply is worded in such a way as to indicate that you think the person you're replying to deserves to be s…

Your reply would be much improved if it were just this part.

> A neutral interpretation would be that "flying blind" is to "operate without perfect information". It is a simple description of operating conditions, not a derogatory term in any way.

Entering it would also have put less wear and tear on the input device.

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

#129

Post by bluGill »

judahmeek wrote: post #124
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…

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.

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

#130

Post by judahmeek »

visiohex wrote: post #122

The core reason most orgs are "flying blind" is that we still don't have a reliable metric for technical debt. Management only tracks shipped features and velocity because they are easy to measure. They completely ignore the hidden liability of a rushed, messy codebase until productivity eventually grinds to a halt. You can't measure the economics of a team if you ignore the balance sheet.

Time to ship, change failure, rework rates, mean time to resolve, code complexity, code churn, average age of dependencies - there's a ton of reliable metrics for technical debt, but they have to actually be looked at to do any good.

The problem is that technical debt is a more complex concept & thus requires more metrics to properly measure than a simple concept like velocity.

Post reply on HN