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

131–140 of 299 posts

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

#131

Post by augustk »

bob1029 wrote: post #37

I don't understand the urgency around quantifying every aspect of the software process. Surely, we are in agreement that money in must at least equal money out if the company is to be viable? This is a simple quickbooks report, is it not? Why don't we instead focus our energies on the customer and then work our way backward into the technology. There are a lot of ways to solve problems these days. But first you want…

Why don't we instead focus our energies on the user. For some very important software applications the customer is not the user. Let the sales department focus on the customer.

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

#133

Post by TheLudd »

brabel wrote: post #91
TheLudd wrote: post #63

Earlier quoted context omitted.

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

No. I am not saying that it is a bad idea to do this.

I am saying:

Given you have saved two hours per person per week

Then the value for the company is _not_ equal to two hourly salaries per week. The consequences are just not that simple.

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

#134

Post by pron »

MattGaiser wrote: post #107
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…

A lot of that can be overcome by including the need to be able to put more floors on top as part of the spec. Whether it be humans or agents, people rarely specify that one explicitly but treat it as an assumed bit of knowledge. It goes the other way quite often with people. How often do you see K8s for small projects?

> A lot of that can be overcome by including the need to be able to put more floors on top as part of the spec

I wish it could, but in practice, today's agents just can't do that. About once a week I reach some architectural bifurcation where one path is stable and the other leads to an inevitable total-loss catastrophe from which the codebase will not recover. The agent's success rate (I mostly use Codex with gpt5.4) is about 50-50. No matter what you explain to them, they just make catastrophic mistakes far too often.

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

#135

Post by devmor »

cmarot wrote: post #32
lknuth wrote: post #10

Making it solely about the extraction of dollars is a great recipe to make something mediocre. See Hollywood or Microslop. Its like min-maxing a Diablo build where you want the quality of the product to be _just_ above the "acceptable" threshold but no higher because that's wasting money. Then, you're free to use all remaining points to spec into revenue.

Exactly. In addition, sometimes a good software "only" makes you save 1% of your time, but that 1% was a terrible burden that induced mental fatigue, made you take bad decisions, etc. It can even make a great Engineer stay when he would have left with the previous version.

While reading the article I was thinking the same thing. I can think of problems I've solved that directly affected 0% of our customers, but overloaded our customer support team.

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

#136

Post by bluGill »

j16sdiz wrote: post #127
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!”

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.

I was involved in a big re-write years ago. The boss finally put the old product on his desk with a sign "[boss's name]'s product owner" - that is when people asked how should this work the most common answer was exactly like the old version. 10 years latter the rewrite is a success, but it cost over a billion dollars. I have long suspected that billion dollars could have been better spend by just fixing technical debt.

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

#137

Post by bluGill »

piker wrote: post #102
ekidd wrote: post #78

Earlier quoted context omitted.

Yeah, I can build a Slack "clone" in a couple of weeks with my own two hands, no AI required. But it's not going to actually be competitive with Slack. Just to pick an incredibly, unbelievably basic enterprise feature, my two-week Slack clone is not going to properly support legal holds. This requires having a hard override for all deletion and expiration options anywhere in the product, that must work reliably, in o…

> It was a cliche for many years that Microsoft Word had "too many features." So people would start companies to sell "lightweight word processors" that only implemented "the most used 20% of features." And most of these companies sank without a trace (with a couple of admirable exceptions that hyperfocused on specific niches). Google finally made progress against the monopoly, but to it, they actually invested in a…

There are at most 5% of the features of word that are common to everyone. Things like spell check everyone uses. Actually I suspect it is more like 0.1% of the features are common, and most people use about 0.3% of the features and power users get up to 5% of the features - but I don't have data, just a guess.

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

#138

Post by throwway120385 »

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…

If I'm managing a company of about 10 people to do something in the physical world, I'd probably skip the PM & QA and hire the engineer and have the engineer task the LLM with QA given a clear set of requirements and then manage the projects given a clear set of deadlines.A good SE can do a "good enough" job at QA and PM in a small company that you won't notice the PM & QA is missing. But the PM & QA can always be added or QA can be augmented with a specialist assuming you're LLM-driven.

Of course if none of your software projects are business-critical to the degree that downtime costs money pretty directly then you can skip it all and just manage it yourself.

The other thing you should probably understand is that the feedback cycle for an LLM is so fast that you don't need to think of it in terms of sprints or "development cycles" since in many cases if you're iterating on something your work to acceptance test what you're getting is actually the long pole, especially if you're multitasking.

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

#139

Post by yosef123 »

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 can spend a lot of time perfecting the test suite to meet your specific requirements and needs, but I think that would take quite a while, and at that point, why not just write the code yourself? I think the most viable approach of today's AI is still to let it code and steer it when it makes a decision you don't like, as it goes along.

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

#140

Post by piker »

bluGill wrote: post #137
piker wrote: post #102

Earlier quoted context omitted.

> It was a cliche for many years that Microsoft Word had "too many features." So people would start companies to sell "lightweight word processors" that only implemented "the most used 20% of features." And most of these companies sank without a trace (with a couple of admirable exceptions that hyperfocused on specific niches). Google finally made progress against the monopoly, but to it, they actually invested in a…

There are at most 5% of the features of word that are common to everyone. Things like spell check everyone uses. Actually I suspect it is more like 0.1% of the features are common, and most people use about 0.3% of the features and power users get up to 5% of the features - but I don't have data, just a guess.

Yeah but 98% of Word features were buried in like 2004. They were added when it was a selling point to use unicorn and gnome icons as your table border in under 100mb of RAM. So we’re talking about 20% of the limited set of features that remain not just for backwards compatibility.
Post reply on HN