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

91–100 of 299 posts

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

#91

Post by brabel »

TheLudd wrote: post #63
radiator wrote: post #50

Earlier quoted context omitted.

In such a clear-cut example, I think we have saved the two hours.

Yes. You work 2 hours less, but what do you produce in those two extra hours? Can you say that your company now spends X dollars less or earns X dollars more? I don't think it can be that clear.

And what is your theory? That it’s better to not save those 2 hours since they will just go to waste anyway? Or that there is diminishing returns to saving work as people will tend to just spend longer on other things they were already doing? How can you be sure those 2 hours will not actually be used by most to do very productive things that in the end look like +4 hours in return??

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

#92

Post by brabel »

watsonjs wrote: post #67

I've been a software engineer for more than ten years and never cared about these kinds of topics. But lately, I've found them genuinely interesting. Could someone recommend books on the economics of software businesses? I can't take this author's content seriously.

I have been interested in this topic for a long time and to be honest, there is no better book on the topic than The Mythical Man Month. Yes from the 70s I think, but still the best I have read.

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

#93

Post by chaboud »

virgilp wrote: post #60
ben_w wrote: post #56

Earlier quoted context omitted.

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

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

Back to the OP, these things aren't calculable, but they'll kill businesses every time.

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

#94

Post by boh »

This is some aggressive consultant fluff. Few companies have such distinctive "profit" measures. If "the financial logic is rarely examined carefully" than maybe there's a reason, since analysis like this is mostly fantastical and brittle. This is the sort of argument that is both rational and implausible. A manager might use this logic to rationalize firing an engineering team (which is mostly why guys like this get hired) but they won't use it to manage an engineering team.

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

#95

Post by pron »

> 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 find out that the walls and beams are made of foam and the art is load-bearing. The entire construction is just wrong, hidden behind a nice exterior. And when you need to add a couple more floors, the agents can't "get through it" and neither can people. The codebase is bricked.

Today's agents are simply not capable enough - without very close and labour-intensive human supervision - to produce code that can last through evolution over any substantial period of time.

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

#96

Post by robertlagrant »

ben_w wrote: post #61
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?

The PMs and QAs I know would disagree with that assessment. > What would you trust more - an engineer doing project management too - or a project manager doing the engineering job? If one of the three, {PM, QA, coder}, was replaced by AI, as a customer I'd prefer to pick the team missing the coder. But for teams replacing two roles with AI, I'd rather keep the coder. But a deeper problem now is, as a customer, perhap…

> The PMs and QAs I know would disagree with that assessment.

It just depends on the org structure and what the org calls different skills. In lots of places now PM (as in project, not product) is in no way a leadership role.

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

#97

Post by fduran »

TheLudd wrote: post #46

One interesting factor that I rarely see discussed is this: Let's say a DevOps person does some improvement to internal tooling and a task that devs had to oversee manually now is automated. Every dev spent about 2 hours per week doing this task and now they don't have to anymore. Now, have we saved 2 hours of salary per dev per week? Not sure. Because it totally depends on what they do instead. Are they utilizing tw…

They have saved _more_ than two hours per dev and week. There's a compound factor and now code can be more reliable (less outages or emergencies fixing bugs) etc. Also having a sane working environment helps engineers not quitting, which is very expensive if they are replaced.

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

#98

Post by clbrmbr »

> There is no cohort of senior product leaders who developed their judgment in conditions where their teams were expected to demonstrate financial return, because those conditions did not exist during the years when that cohort was learning the craft.

There totally is such a cohort. There are plenty of bootstrapped companies or startups that took only an angel round and did not benefit from the low rate environment, in fact they suffered because of the very high price of SWE labor. But those engineering managers exist and are out there right now still building efficiently, quietly growing, passionately serving customers, and keeping a close eye on the bottom line and risks because that’s their livelihood.

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

#99

Post by sarchertech »

> 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. The liability argument holds in a human-to-human or agent-to-human world. In an agent-to-agent world, it largely dissolves.

What experience is this guy basing this on? My guess is absolutely none at all.

Maybe this will be the case in the future, but as of right now if I cut 10 agents loose for 10 days one of our repos at work and tell them to clean it up but but keep the tests passing, we’d be drowning in support tickets.

Tests don’t cover all observable behavior. Every single production bug we’ve had made it through the test suite.

Also this guy only had a vague idea of how platform engineering teams work in large organizations.

Platform teams are the engineering org’s immune system. They’re how we fight back against the tech debt accumulated by the relentless march of features of the week.

If anything the extra code people are cranking out with AI make them more necessary.

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

#100

Post by joshwillik »

> The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. […] The liability argument holds in a human-to-human or agent-to-human world. In an agent-to-agent world, it largely dissolves.

Maybe there’s some new paradigm that makes this true. But it doesn’t seem obviously true to me.

Humans make the best code long term when everything orbits a vision of the underlying problem space.

LLMs seem to only consider the deeper problem space when I explicitly flag it for them, otherwise they write “good enough for this situation” type code. And that stack of patches type code is exactly how the code becomes messy and complicated in the first place.

Post reply on HN