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

141–150 of 299 posts

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

#141

Post by Kubuxu »

bluGill wrote: post #129
judahmeek wrote: post #124

Earlier quoted context omitted.

Something is missing in the common test suite if this can occur, right?

You have to fight to get agents to write tests in my experience. It can be done, but they don't. I've yet to figure out how get any any agent to use TDD - that is write a test and then verify it fails - once in a while I can get it to write one test that way, but it then writes far more code to make it pass than the test justifies and so is still missing coverage of important edge cases.

I have TDD flow working as a part of my tasks structuring and then task completion. There are separate tasks for making the tests and for implementing. The agent which implements is told to pick up only the first available task, which will be “write tests task”, it reliably does so. I just needed to add how it should mark tests as skipped because it’s been conflicting with quality gates.

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

#142

Post by bwestergard »

tsukikage wrote: post #57
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…

https://de.wikipedia.org/wiki/Sitzredakteur

Amazing bit of history, thank you!

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

#143

Post by _heimdall »

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?

QA is still alive and well in many companies, including manual QA. I'm sure there's a wide range these days based on industry and scale, but you simply don't ship certain products without humans manually testing it against specs, especially if its a highly regulated industry.

I also wouldn't be so sure that programming is the hardest of the three roles for someone to learn. Each role requires a different skill set, and plenty of people will naturally be better at or more drawn to only one of those.

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

#144

Post by bluGill »

jascha_eng wrote: post #64
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…

The longer software is sold the more you need to maintain it. In year one most of the cost is making it. Over time other costs start to add up.

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

#145

Post by steveBK123 »

ThunderSizzle wrote: post #86
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)?

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 -> document the feature -> deploy the feature -> support the feature in production from on-call rotation.

Often I have a few juniors or consultants working for me that I oversee doing parts of the implementation, but thats about it.

The talking to users part is where a lot of people fall down. It is not simply stenography. Remember most users are not domain/technical experts in the same things as you, and it's all just a negotiation.

It's teasing out what people actually want (cars vs faster horses), thinking on your feet fast enough to express tradeoffs (lots of cargo space vs fuel efficiency vs seating capacity vs acceleration) and finding the right cost/benefit balance on requirements (you said the car needs to go 1000 miles per tank but your commute is 30 miles.. what if..).

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

#146

Post by kloop »

diatone wrote: post #35
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…

You’re illustrating one of the points of TFA - a team that is equipped with the right tools to measure feature usage (or reliably correlate it to overall userbase growth, or retention) and hold that against sane guardrail metrics (product and technical) is going to outperform the team that relies on a wizardly individual PM or analyst over the long term making promises over the wall to engineering.

Feature usage can't tell you that.

There's often a checklist of features management has, and meeting that list gets you in the door, but the features often never get used

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

#147

Post by kevin_nisbet »

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 calendar, with 15 attendee's, costing x dollars in wages, that produces no value for the customers because the lesson was already learned.

Or when reacting to an incident of some sort, it's so easy to have a long list of action items that may theoretically improve the situation, but in reality are incredibly expensive for the value they produce (or the risks they reduce). It's too easy to say, we'll totally redesign the system to avoid said problem. And what worries me, is often those very expansive actions, then cause you to overlook realistic but small investments that move the needle more than you would think.

And as a hot topic I also think the costs are an input into taking on tech debt. I know we all hate tech debt with a passion, but honestly, I think of it as a tool that can be wielded responsibly or irresponsibly. But if we don't know what our attention costs, we're going to have difficulty making the responsible choices about when and where to take on this debt. And then if we're not conscious about the debt, when it comes do it stings so much harder to pay down.

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

#148

Post by bluGill »

XCabbage wrote: post #80
jascha_eng wrote: post #64

Earlier quoted context omitted.

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…

> Building a piece of software is or at least was orders of magnitudes more expensive than maintaining it This feels ludicrously backwards to me, and also contrary to what I've always seen as established wisdom - that most programming is maintenance. (Type `most programming is maintenance` into Google to find page after page of people advancing this thesis.) I suspect we have different ideas of what constitutes "main…

> that most programming is maintenance.

What do you mean by maintenance?

A strict definition would be "the software is shipping but customers have encountered a bug bad enough that we will fix it". Most work is not of this type.

Most work is "the software is shipping but customers really want some new feature". Let us be clear though, even though it often is counted as maintenance, this is adding more features. If you had decided up front to not ship until all these features were in place it wouldn't change the work at all in most cases (once in a while it would because the new feature doesn't fit cleanly into the original architecture in a way that if you had known in advance you would have used a different architecture)

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

#149

Post by philsnow »

> Most engineers do not know this number.

How could they not? When I penciled this out ~18 years ago, I included the amortized cost of all the interviews it took to hire a given engineer as well. It's not rocket surgery, as they say.

Money can be exchanged for goods and services.

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

#150

Post by ggregoire »

jwpapi wrote: 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…

Also, it's obviously faster to copy Slack 1-to-1 than inventing it from scratch. Making Slack was not just coding.
Post reply on HN