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

61–70 of 299 posts

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

#61

Post by ben_w »

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?

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, perhaps I can skip the team entirely and do it all myself? That way, no game of telephone from me to the PM to the coder and QA and back to me saying "no" and having another expensive sprint.

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

#62

Post by dude250711 »

DeathArrow wrote: post #45

>Given that software teams are expensive In many companies there are 3 to 5 other people per developer (QA, agile masters, PO, PM, BA, marketing, sales, customer support etc.). The costs aren't driven just by the developer salaries. A CEO can cost as much as 10 developers, sometimes more.

That is why I respect Zuckerberg: he did not participate in Google's and Apple's salary fixing and he is willing to pay new tech hires insane money.

There is something different about CEOs that came from tech.

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

#63

Post by TheLudd »

radiator wrote: post #50
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…

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.

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

#64

Post by jascha_eng »

InfinityByTen wrote: post #7

When I see someone just throwing a lot of numbers and graphs at me, I see that there are in to win an argument, and not propose an idea. Of late, I've come across a lot of ideas from Rory Sutherland and my conclusion from listening to his ideas is that there are some people, who're obsessed with numbers, because to them it's a way to find certainty and win arguments. He calls them "Finance People" (him being a Market…

None of his math really checks out. Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it. But how much money it can make is potentially unbounded (until it gets replaced).

So investing e.g. 10 million this year to build a product that produces maybe 2 million ARR will have armortized after 5 years if you can reduce engineering spend to zero. You can also use the same crew to build another product instead and repeat that process over and over again. That's why an engineering team is an asset.

It's also a gamble, if you invest 10 million this year and the product doesn't produce any revenue you lost the bet. You can decide to either bet again or lay everyone off.

It is incredibly hard or maybe even impossible to predict if a product or feature will be successful in driving revenue. So all his math is kinda pointless.

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

#65

Post by febusravenga »

csomar wrote: post #33
sdevonoes wrote: post #27

Still don’t understand what regular people (like the author) gain from selling how wonderful AI is. I get that the folks at Anthropic and openai shove AI through our throats every day, but nobodies?

He is selling consulting around AI/LLM.

In other words, he's cutting branch he's sitting on.

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

#66

Post by groby_b »

I see we're once again missing the existence of indirect impact. There's a reason organizations look at revenue/engineer overall instead of trying to attribute it directly to specific teams.

I guess his students get to relearn that on their own.

Also, any post talking about building software and then contains the suggestion that "cost per unit" is an efficiency metric needs to come to the red courtesy phone, Taylorism would like to have a chat about times gone by.

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

#67

Post by watsonjs »

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.

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

#68

Post by MattGaiser »

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…

In general, there’s very little info that costs much to learn nowadays. The human standing in the front is a disciplinarian to force you to learn it.

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

#69

Post by catmanjan »

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

I mean, yes?

Maybe it's different where you live but QA pretty much disappeared a few years ago and project managers never had anything to do with the actual software

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

#70

Post by kcexn »

I feel like there is a lot of nuance around this topic that is getting lost in the noise.

The direct and indirect financial impact of technical decisions are indeed hard to measure. But some technical decisions definitely have greater financial impact than others. Even if it's hard to precisely quantify the financial costs/benefits of every decision. It is possible to order them relatively. X is likely to make more money than Y. So we do X first and Y later.

There is a significant amount of chance involved in whether a product/feature will even make money at all. So even good plans with measurably positive expected value could end up losing money.

Just because it's impossible to be 100% certain of the outcome of any decision. Doesn't mean we should throw the baby out with the bathwater.

Post reply on HN