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

191–200 of 299 posts

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

#191

Post by latentsea »

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…

They can work really well if you put sufficient upfront engineering into your architecture and it's guardrails, such that agents (nor humans) basically can't produce incorrect code in the codebase. If you just let them rip without that, then they require very heavy baby-sitting. With that, they're a serious force-multiplier.

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

#192

Post by travisgriggs »

rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.

HARD AGREE. But…

Taken as just such, one might conclude that we should spend less time writing software and more time in design or planning or requirement gathering or spec generating.

What I’ve learned is that the painful process of discovery usually requires a large contribution of doing.

A wise early mentor in my career told me “it usually takes around three times to get it right”. I’ve always taken that as “get failing” and “be willing to burn the disk packs” [https://wiki.c2.com/?BurnTheDiskpacks]

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

#193

Post by TheGRS »

The points brought up are all great. I'm in a lower management position and I've wondered for a decade why the budget, cost, and return on work (i.e. revenue) were never divulged or connected to the work at hand. So kudos for facing that problem bluntly in language that's easy to follow. The place I'm at currently, its much more about automating away processes and making back office operations easier, so there's likely a lot of direct cost savings that we could measure, but don't.

Here's the problem I see with how this particular article is moving though: the context of these projects are often highly technical connecting back to the human problem space. Developers sit on the technical end but they also usually have a mental model for how it connects back to the non-technical. A product manager is another addition to compensate for the user connection. Between all of these folks they can only hold so much in their head about the problem space on a day-to-day basis. And that headspace for the problem is what is critical. Management wants to try a new idea for sales? They need to take it to the team with that problem space to translate it into working code. Even with the assistance of agents, one needs to hold the important patterns in their head. And my company certainly isn't going to vibe code its way through anything regulatory, mistakes there might cost us a ton in fees and bad PR. Hell I've seen product managers sweat over the possibility of getting a few 1 star reviews on the app store.

Anyway, you still need people with context to break things down and get them out the door, the agents can just assist with the speed of the In Progress stage. And clever teams can figure out how to automate their validation (but they could already do that).

Rockstar developers often seem to be the ones who can parachute in, gain context, make changes, and leave to find another problem space. They get bogged down when they've visited 10 or more problem spaces and then they start getting called back into service. Again the agents don't change any of that, the human involved has a finite capacity for context.

Teams who structure around maintaining context might be best suited for the new world of code.

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

#194

Post by sarchertech »

highfrequency wrote: post #183
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

Agreed, but are you also implying that the process of iteratively "programming something that's not it, and then replacing it" multiple times is not in the scope of what LLMs can/will do?

Most of the time taken during this process is spent getting feedback, processing it, and learning that it's not it. So even if LLMs drive the build time to zero, they won't speed up the process very much at all. Think 10% improvement not 10x improvement.

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

#195

Post by RamblingCTO »

I do tech dd, exit readiness and post merger integration in tech companies and this is my daily bread. The biggest lever I have: connecting initiatives to ROI/bottom line impact. It's incredible how blind product/software teams run. So much to do but most of it won't make any money and just feels productive. Connecting activities and work directly towards revenue is very important.

If your company runs well: won't hurt you much that you're not doing this. Otherwise this will be your end. And that really hurts because you lose the economical impact of the product and the jobs.

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

#196

Post by RamblingCTO »

kevin_nisbet wrote: post #147

I'm not commenting too much on the details of the article, but the premise does resonate with me. I would argue all the engineering teams I've been on do not spend enough time thinking about how much a piece of work will cost to execute, and whether it will generate a return. I suspect this is most apparent on things like meeting culture. Something happens and all of a sudden there is another recurring meeting on the…

Meetings aren't even the worst resource wasters. Wrong initiatives, features, apps/platforms/services are. They capture future resources in form of maintenance and complexity with them.

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

#197

Post by shimman »

siliconc0w wrote: post #185
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

+1 A huge amount of software - probably most - is not actually generating value and in many cases is actually reducing value. I've seen teams build and re-build the same infrastructure over and over. I saw a request that could have been met with a few SQL queries and a dashboard got turned into a huge endeavor that implements parts of an ETL, Configuration Management, CI/CD, and Ticketing system and is now in the cri…

Incentive of undemocratic groups is to build mini-empires yes, but if the business decisions were led by workers instead of a group of tyrants it'll most likely be a better decision. If we want lived examples of this, look at recorded history.

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

#198

Post by pron »

latentsea wrote: post #191
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…

They can work really well if you put sufficient upfront engineering into your architecture and it's guardrails, such that agents (nor humans) basically can't produce incorrect code in the codebase. If you just let them rip without that, then they require very heavy baby-sitting. With that, they're a serious force-multiplier.

They don't work really well even on relatively small things and even with a virtually impractical upfront engineering: https://news.ycombinator.com/item?id=47752626

They just make a lot of mistakes that compound and they don't identify. They currently need to be very closely supervised if you want the codebase to continue to evolve for any significant amount of time. They do work well when you detect their mistakes and tell them to revert.

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

#199

Post by marcosdumay »

steveBK123 wrote: post #145
ThunderSizzle wrote: post #86

Earlier quoted context omitted.

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…

> That entire role is software engineering. Many in the industry suck at most of the parts and only like the programming part. I'm always amused when I read anecdotes from a role siloed / heavily staffed tech orgs with all these various roles. I've never had a spec handed to me in my career. My job has always been been end to end. Talk to users -> write spec into a ticket -> do the ticket -> test the feature -> docum…

> I've never had a spec handed to me in my career.

We call those places "feature factories".

I have been required to talk with many in my life, I have never seen one add value to anything. (There are obvious reasons for that.) But yet, the dominant schools in management and law insist they are the correct way to create software, so they are the most common kind of employment position worldwide.

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

#200

Post by zingar »

CodeMage wrote: post #184
rossdavidh wrote: post #162

All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part. For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to…

> the actual programming is not the hard part We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard .

Hard perhaps but it feels a lot easier now than three years ago. Or so my backlog of personal projects outside of my most familiar stack would suggest.
Post reply on HN