Live data from Hacker News

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

viktorcessan.com

81–90 of 299 posts

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

#81

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

Or, more likely, a snake oil seller dedicating more to marketing than to the product.

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

#82

The 3-5x return threshold is the part most eng leaders never internalize. I've seen teams spend entire quarters on internal tooling that saves maybe 20 minutes per developer per week — nowhere near break-even, let alone a healthy return. The uncomfortable truth is that most prioritization frameworks (RICE, WSJF, etc.) deliberately avoid dollar amounts because nobody wants to see the math on their pet project. Once yo…

On the other hand, I’ve also seen single developers create a tool or dashboard off-the-books that had widespread adoption. Things that would never have breached the top 100 features list since they are entirely internal. The irony is then they are expected to maintain it indefinitely without official effort allocation.

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

#83
post #60
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?

QA merged originally out of programming.

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

#85
post #72

I thought it was a good article, till I saw the Slack example. The copy doesn’t even remotely grasp the scale of what the actual Slack sofware does in terms of scale, relaiability, observability, monitorability, maintability and pretty sure also functionality. Author only writes about the non-dev work as difference, which seems like he doesn’t know what he’s talking about in all, and what running an application at th…

Absolutely, the moment I saw „95% of Slack core functionality” I stopped believing the author knows what he’s talking about

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

#86
post #56
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)?

That's the difference between programming and software engineering.

A software engineer should be able to talk directly to customers to capture requirements, turn that into spec sheet, create an estimate and a bunch of work items, write the whole system (or involve other developers/engineers/programmers to woek on their work items), and finally be able to verify and test the whole system.

That entire role is software engineering. Many in the industry suck at most of the parts and only like the programming part.

I think the hardest part is requirements gathering (e.g. creating organized and detailed notes) and offloading work planned work to other developers in a neat way, generally speaking, based on what I see. In other words, human friction areas.

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

#87
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…

[flagged]

If a test suite runs for either 6 minutes or 66 seconds I am not staring at it while it runs. I am doing something else. So that is not holding up my time

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

#88
post #25

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

I got 99 problems but an agent ain’t one.

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

#89
I think the article make some great points, however this part is not even wrong:

"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 familiarity with the codebase matters less than it once did. 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."

LLMs are not conscious, that means left on their own devices they will drift. I think the single most important issue when working with LLMs is that they write text without a layer that are aware what's actually being written. That state can be present in humans as well, like for example in sleepwalking.

Everyone who's tried to to complete vibe coding a somewhat larger project knows that you only get to a certain level of complexity until the model stops being able to reason about the code effectively. It starts to guess why something is not working and cannot get out of that state until guided by a human.

That is not new state in the field, I believe all programmers has at points in their career come across code that's been written with developers needing to get over a hard deadline with the result of a codebase that cannot effectively be modified.

I think for a certain subsets of programming projects some projects could possibly be vibe coded as in that code can be merged without human understanding. But it has to be very straightforward crud apps. In almost everything else you will get stopped by slop.

I suspect that the future of our profession will shift from writing code to reading code and to apply continuous judgement on architecture working together with LLMs. Its also worth keeping in mind that you cannot assign responsibility to an LLM and most human organization requires that to work.

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

#90
post #78
post #72

I thought it was a good article, till I saw the Slack example. The copy doesn’t even remotely grasp the scale of what the actual Slack sofware does in terms of scale, relaiability, observability, monitorability, maintability and pretty sure also functionality. Author only writes about the non-dev work as difference, which seems like he doesn’t know what he’s talking about in all, and what running an application at th…

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…

When I look at the big non-tech industry companies that have a chill life and print money. It’s usually the companies that are just the very best in what they do and have a quasi monopoly or so much competitive andvantage that everybody is just using them.

That’s whats need in tech too.

A clone doesn’t get you closer to that.

Post reply on HN