4 ms·
>Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize. I think this is probably going to happen
by thfuran 5mo ago
>Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize.
I think this is probably going to happen at the same time that the providers start really jacking up token prices to extract all the value they can.
- SlinkyOnStairs 5mo agoAlmost certainly. Software firms are pretty bad at self-evaluation and they're profitable enough that Capitalism won't force them to do it either. Right now the subscriptions are still in the range of reasonable business expenses, but pretty soon they'll have to jump and $200/month/seat subscriptions turning into $2000/month/seat subscriptions is going to get even very badly ran companies to re-evaluate.
- busterarm 5mo agoIt's worse than that. Developers themselves are drunk. They'll be cut off from tools right when they no longer understand the underlying code they're responsible for. We're already here even. I know of a company that was doubling their Codex spend and hitting the cap week over week and finally they had enough and stopped increasing. Then they maxed out on credits and had a week of no Codex. A large percentage of the engineers loudly refused to work for the rest of the week. They were managing the Codex managing the codebase and were totally incapable of dealing with its output without it.
- jimmypk 5mo ago[flagged]
- cdud3 5mo agoAmen. We are still running highly unoptimized workflows in AWS and nobody reviews why we spend so much $ on that now while it was peanuts when we did it all ourself.
- daheza 5mo agoI'm a manager and the VPs are starting to ask - how many story points are we getting with AI now. Now we do story points = number of days to implement. (I know this is not real agile but just assume you are in the same position) I can't answer that question but plenty of other managers are fully ready to just give bogus numbers. For my team, use of AI has indeed lowered the story point cost. The coding part of the story takes less work so we have started to lower the story point cost for stories that would previously cost more. Think of a 5SP to 3SP reduction. We have increased the number of features being delivered but our number of story points delivered has remained static.
- SoftTalker 5mo ago> story points = number of days to implement Some variant of this has been the case in every agile team I've ever worked on.
- tardedmeme 5mo agoI've always asked for it when joining a team to calibrate my story point estimates. At some teams 1 point is about a half hour task and at other teams it's a full day.
- recursive 5mo agoNo one's ever been able to explain story points to me without saying something like "Story points are kind of like how long it will take to implement, except it's not that". So what is it then? All the explanations and examples are in units of time, but with a disclaimer saying that the true nature of story points is not time-based, except for the fact that they can only be explained in terms of time.
- Terr_ 5mo agoIANAScrumlord, but ideally story points are like a foreign currency: It's both normal and healthy for exchange rates to constantly fluctuate, and every country (team) has it's own units for capturing guesswork and confidence and quality/speed mix. The managerial goal is to take near-past moving average rates (from completed tickets) and use them to forecast near-future expectations. 1.0 of Team Alpha's points might mean 4 hours this week... but anybody who shows up six months later expecting exactly the same rate is foolish, doubly-so if they expect it to be the same across teams, or after a big change in staff or tooling or project. ______ Other musings: Whenever a manager says "my current estimate of the rate is X pts/hr, use that when sizing", I feel it's a mistake. I kills off the intuition you really want to capture. Team members ought to be comparing expected tasks to past tasks. Also, the goal of "accurate scheduling predictions" exists in conflict with "measure employee output". Trying to use your point-system for one generally harms the other.