[deleted]
The economics of software teams: Why most engineering orgs are flying blind
251–260 of 299 posts
Re: The economics of software teams: Why most engineering orgs are flying blind
#252I 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.
The user is always a customer of the product in my mind. I don't use the term to mean a purely financial relationship.
Re: The economics of software teams: Why most engineering orgs are flying blind
#253Earlier quoted context omitted.
I am spending about 10h per day solving chemical engineering problems (dynamic simulation, model predictive control, etc.). The programming is hard on top of hard science. Even after 25 years of experience, it is still hard to find the right abstraction to implement everything. Still, one thing I really like with LLM/AI, is that now, I can allow myself to test different abstractions a bit faster. I can allow myself t…
I suppose the complexity of the domain is the main driver of the difficulty level. Perhaps that's the intuition that I'm trying to pin down: programming itself, the typing of words for the compiler, the act of converting pure thought into code, seems mechanical at best. But if you include the act of abstraction itself, then I concede it changes the equation. I don't find it to be all that clear what is and isn't prog…
[deleted]
Re: The economics of software teams: Why most engineering orgs are flying blind
#254> 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?
Maybe, and that unknown unknown is the biggest footgun with LLMs in just about every regard.
Re: The economics of software teams: Why most engineering orgs are flying blind
#255> 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…
[dead]
Re: The economics of software teams: Why most engineering orgs are flying blind
#256Earlier quoted context omitted.
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 responsib…
Continuous delivery really killed QA.
[dead]
Re: The economics of software teams: Why most engineering orgs are flying blind
#257Earlier quoted context omitted.
If a SWE could truly output 20x their effort, that person would probably be better at freelancing or teaming up with another SWE. If something can be automated away to AI is Project Management. Also, there has to be a point where delivering more and faster code doesn’t matter, because the choke points are somewhere else in the Project Life Cycle, say waiting for legal, other vendors, budgets, suppliers, etc, so produ…
> If a SWE could truly output 20x their effort, that person would probably be better at freelancing or teaming up with another SWE. Yes but this requires the willingness to take on the additional stress and risk of managing your own sales, marketing, accounting, etc.
If AI can 20x an engineer, it can handle all this too.
Sadly it can’t.
Re: The economics of software teams: Why most engineering orgs are flying blind
#258Earlier quoted context omitted.
> Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself? Being able to transcribe sentences in a certain language is the skill kids pick up in elementary schools. Being a writer requires a whole set of skills built on top of that. The reason why I brought up that difference in the…
> Writing code that solves your users' requirements is "programming". For me, I need to have a solution figured out before writing code. I am not even sure how you could write code before having the problem solved. Your approach would be insightful. Like, I get it is effectively impossible to gather all user requirements upfront and that you need to build a product to find out what details you overlooked. That means…
> Writing code is just means of conveyance, no?
Yes, which is why I have been making the distinction between "programming" and "writing code" all this time.
Programming is hard because it's not merely writing code. Determining what to program is not the same as determining what code to write. "What to program" is about requirements. Going from "what to program" to "what code to write" is what programming is about.
Re: The economics of software teams: Why most engineering orgs are flying blind
#259Earlier quoted context omitted.
If a SWE could truly output 20x their effort, that person would probably be better at freelancing or teaming up with another SWE. If something can be automated away to AI is Project Management. Also, there has to be a point where delivering more and faster code doesn’t matter, because the choke points are somewhere else in the Project Life Cycle, say waiting for legal, other vendors, budgets, suppliers, etc, so produ…
> If a SWE could truly output 20x their effort, that person would probably be better at freelancing or teaming up with another SWE. Yes but this requires the willingness to take on the additional stress and risk of managing your own sales, marketing, accounting, etc.
Except now you also team up with people who are adept at sales, marketing, accounting, etc. now to form a cooperative instead of a corporation. Maybe workers can get back some of the rights and fruits of their labor.
Re: The economics of software teams: Why most engineering orgs are flying blind
#260more ai articles on my front page :(