Hacker News new | past | comments | ask | show | jobs | submit
nbajka | on: We should be more ambitious with the software we build
>Burning down the backlog to zero doesn't mean the development team will be subsequently laid off. Quite the contrary. It will create a vacuum that the business will fill with new work

Will it? Are you willing to test this?

>No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks.

If there are no remaining items, or the amount of items processed per day has increased well above the amount of items that need processing every day, someone's certainly getting laid off.

>Who would support all the potential bugs they just created?

We have long criticised management for not caring about this. Now we are supposed to trust their good judgement?

unsloppable | parent | next
Keeping the backlog funnel full has been nearly a full ltime job for me for about 5 years now. Both pre and post AI. Once you get a team together that knows how to execute keeping the backlog full of well defined and groomed tasks becomes the problem management rarely sees and subsequently doesn't know how to solve.
throw-qqqqq | root | parent | next
This.

I recently switched, but at my previous job, the PMs (who would typically do most of this work) got so overworked after AI took hold, that they’ve doubled the PM-to-dev ratios on all (the productive) teams.

I have read about this in other companies as well. Some teams in Google have a PM pr dev, I hear.

Where I work now, sh*t gets done MUCH quicker with AI, and to a higher quality as well.

IMO, if you work with software and can’t get a meaningful boost out of AI, I think you’re doing something wrong.

gedy | root | parent
I think that's why you keep hearing about all these tech stack rewrites.

Many of these companies have no idea what to do to begin with, so improving dev throughput is not really the business problem to begin with (even though frequently blamed).

chasd00 | root | parent
Trying to fill a backlog to just keep a dev team busy is not what a backlog is for. It would be better for the business to have them rake leaves out front than add to a system something no user needs for the sole purposes of looking busy.
cweld510 | root | parent
I think the assumption is that there are clearly problems to solve and useful work to do, but that useful work is not always well-defined enough to be ticketed and represented in the backlog as individual parallelizable work items.
joshuahedlund | parent | next
> If there are no remaining items

In every software job I’ve ever had, every released new feature leads to maybe three new requests to modify the new feature, two unintentional bug tickets, plus some tech debt. Work leads to more work, not less. I don’t see how increasing the velocity of the work should change that.

mbesto | parent | next
> Will it? Are you willing to test this?

Yes, this literally happens all of the time today. Proof point - software development organizations hire to fill operating budget voids, not on what work needs to be done.*

*Source - I've seen 900+ software team's P&Ls and interviewed their CTOs.

1over137 | root | parent
Crazy. But this is surely only true in mega corps, it’s nothing I’ve ever seen in small orgs.
weitendorf | parent
[flagged]
nbajka | root | parent | next
>Nobody wants to lay off an employee that is pleasant to be around, trustworthy, and good at what they do.

So if I hire a painter who is pleasant to be around, trustworthy, and good at what they do, I'm not going to "lay him off" the instant he's done painting my house?

loading story #50230095
loading story #50230215
qyph | root | parent
This is an absolutely unhinged personal attack on the op that has nothing to do with their comment. Why do you assume they are intentionally slowing things down? Because their analysis of the situation is that some people will be fired?
loading story #50230130
loading story #50230124