| ▲ | SlinkyOnStairs 2 days ago |
| > Development speed was never the bottleneck; it's all the other processes that take time: infra provisioning, testing, sign-offs, change management, deployment scheduling etc. So much of Management (both mid and executive) still considers Software as if it were an assembly line; "We make software just like how Ford makes cars". Code as a product. Which isn't to say that most software development isn't woefully inefficient, but the important bits aren't even considered. "The Work" is seen as being writing code, not the research that goes into knowing what code has to be written. And for AI marketing, this is almost a videogame-esque weakspot. Microsoft proclaims "50% faster code!" and every management fool thinks "50% faster product; 50% faster money!" > Large enterprises need to learn how to ship software faster if they want to lock in ROI on their token spend. It's going to be a disaster once ROI is demanded. Right now everyone is fine with not measuring it; Investors are drunk on hype and nobody within the company actually wants to admit that properly measuring software development productivity is almost impossible. But the hype won't last forever. Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize. Copilot and Claude won't be tackling the real bottlenecks. They're not going to dredge up decade old institutional knowledge, they won't figure out whether code looks bad because it is bad or because it solves a specific undocumented problem, they won't anticipate future uses. Code just isn't the product. Not the real work. Really, if your codebase is in a healthy state, it's often a literally free output of the design and research processes. By the time you've refined "our procurement team finds the search hard to use" into a practical ticket, the React component for the appropriate search filters has basically already been written, writing up the code is just a short formality. Asking Copilot would turn a 10 minute job into a 5 minute job. Real impressive, were it not for the 6 hours of meetings and phone calls that went into it. |
|
| ▲ | SoftTalker 2 days ago | parent | next [-] |
| "We make software just like how Ford makes cars". People who say this kind of thing probably have no idea how Ford makes cars either. The assembly line is the last step. All the research, design, engineering, and testing happens before any sheet metal is stamped out. So the comparison might be more true than not, but unknowingly. |
| |
| ▲ | Ma8ee 2 days ago | parent | next [-] | | Exactly. It's just that they mix up the steps. The last step, the assembly, is highly automated and usually very fast in software production, since it is done by a compiler (and the aptly named, assembler). The people involved are doing engineering and design, which is much harder to control. | | |
| ▲ | AnimalMuppet a day ago | parent [-] | | Not even that. It's done by the CD duplicator (or, these days, by the web server). |
| |
| ▲ | agentictrustkit 16 hours ago | parent | prev | next [-] | | Yeah I don't think enough people talk about this. AI makes your existing process faster, but it doesn't make a broken process correct. We've seen this at every inflection point — cloud, agile, microservices, now AI. My bet is that the orgs that wil win are the ones NOT with the best models but those that know how to ship! If your lead time from commit to prod is six months, all Cursor does is let you write the wrong thing faster. | |
| ▲ | qznc a day ago | parent | prev | next [-] | | Yes, they confuse development with manufacturing/assembly. | |
| ▲ | Brian_K_White 2 days ago | parent | prev | next [-] | | It's not true at all. In software, the factory line is nothing but cp or httpd and neither costs nor produces any value. In cars, the factory line both costs and produces all the value. | | |
| ▲ | jldugger 2 days ago | parent | next [-] | | > the factory line both costs and produces all the value. I think the point OP is trying to make is that manufacturing and design are seperate steps with different workflows and expectations. And that the design step does have value, as without it your factory line has nothing particular to make or sell. Nobody is sitting around Ford trying to make the clay modeling step faster or more error free, it's a design function. But there are hundreds of software execs out there trying to do exactly that. In part because cp and git and make and your other build tools that make up the factory line function are pretty much rock solid and cost optimized to nearly free. | |
| ▲ | saltcured 2 days ago | parent | prev | next [-] | | Wait, I thought it was the auto company financial services division that produces all the value. The design, factory, supply chain, etc. is just the marketing arm for the loans... | |
| ▲ | ambicapter 2 days ago | parent | prev | next [-] | | Really? So all the designers and engineers at Ford who don't have an iota of a car built by the time they're done with their work aren't producing any value? | | |
| ▲ | thephyber 2 days ago | parent | next [-] | | Marketing and finance are also very large components of cost and value, respectively. It was a short pithy sentence, but it does have a kernel of truth to it. | |
| ▲ | Brian_K_White 2 days ago | parent | prev [-] | | The design is like the electricity to the factory. You need it or else you get no cars at all, but it's a small percentage of the total resources consumed and produces no value at all directly. |
| |
| ▲ | pseudohadamard a day ago | parent | prev | next [-] | | > In software, the factory line is nothing but cp or httpd Little-known fact, cp is actually an AI. I trained my cp AI on a copy of the gcc source code and asked it to write me a C compiler and it did! It was so accurate it even managed to reproduce gcc's bugs and quirks. | |
| ▲ | B1FF_PSUVM 2 days ago | parent | prev [-] | | > In cars, the factory line both costs and produces all the value. Does that apply to phones? |
| |
| ▲ | AngryData a day ago | parent | prev [-] | | Atleast 90% of the time whenever someone mentions Ford it is to spew out Ford PR garbage they once heard that they took as real history instead of the marketing it really is. It really should be held up as an example of how powerful well designed PR is and the myths it generates. |
|
|
| ▲ | thfuran 2 days ago | parent | prev | next [-] |
| >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. |
| |
| ▲ | daheza 2 days ago | parent | next [-] | | I'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. | | |
| ▲ | nradov 2 days ago | parent | next [-] | | When management starts tracking improvements in story point productivity then the agile teams inflate their story point estimates. Sometimes this involves splitting user stories in ways that don't really make sense from a customer perspective just for the sake of having a place to tack on more points. And I'm not opposed to using story points, they have some utility within an agile team or program. They just aren't a valid way of quantifying productivity changes. | | |
| ▲ | at-fates-hands a day ago | parent [-] | | A few years ago I was on a massive project to rebuild and redesign a major public facing portal. Our dev team was nails, cranking out features and components on a very tight time table. Several other teams were inflating their story point estimates so when the higher ups would get their weekly reports, our team was always in dead last for completing story points. Our manager brought us into an all hands meeting and kind of read us the riot act because now we were on "Bob the executive" radar because it looked like we really weren't delivering much week by week. Had anybody actually looked at the amount of work we were doing and what we were shipping, it wouldn't be close. Exactly as you predicted, we started over inflating our stories, creating Epics when they weren't needed, breaking out a single feature into a dozen or more stories. Over the next few weeks, we were all getting pats on the back for "really picking up the pace". When in reality, we were just doing the same thing we always did. It just reinforced the idea that Agile had turned into a system that was easy to manipulate to create the illusion you were doing more than you really were. I imagine we're going to see a lot more of this as C-Suite folks start clamoring for ROI on the millions they're spending on tokens. |
| |
| ▲ | blairharper 13 hours ago | parent | prev | next [-] | | > use of AI has indeed lowered the story point cost It should not have. At least not significantly. Points should represent complexity, risk and overall effort (review burden, testing burden, dependencies, etc.), and so AI should increase velocity before it decreases story point estimates. Over time, if a team's baseline delivery model genuinely changes, then reference stories can be recalibrated, but casually saying "AI lowered the point cost" is usually a smell that points are being treated as time estimates. This is the same reason points should not = days even without AI. Velocity is what tells you if a team is getting better through training, tooling, hiring/firing, or process improvements. Re-pointing the same class of work downward hides the gain. | |
| ▲ | SoftTalker 2 days ago | parent | prev | next [-] | | > story points = number of days to implement Some variant of this has been the case in every agile team I've ever worked on. | | |
| ▲ | recursive a day ago | parent | next [-] | | No 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_ a day ago | parent | next [-] | | IANAScrumlord, 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. | |
| ▲ | tweetle_beetle a day ago | parent | prev | next [-] | | I once met someone who refused to engage with leadership using his team's story points as a direct measure of productivity. To make it harder to extract the data and compare against other teams, they moved to using names of animals to represent types of task associated with differing amounts of uncertainty. I've also seen a supplier who was asked to provide some kind of tracking, where literally nothing existed. Their delivery team produced reports with story points per person, per task, per sprint. Every sprint, every person hit their target month after month after month. They were asked to stop. | |
| ▲ | koyote a day ago | parent | prev | next [-] | | I always see SP a combination of time and risk. I think a lot of people do not include risk in the estimate. So a story might be estimated at 3SP to implement but there's a high risk that it would blow out (e.g. idea was not fully proven in a PoC, work is in an area that is historically underestimated, reliance on a different team, etc.), so we set it to 5SP to include that risk. Maybe 50% of the time it does get finished in what a normal 3SP would finish in, but at least we've covered the 50% of time it blows out. | | |
| ▲ | Terr_ 11 hours ago | parent [-] | | IMO it's best to welcome the addition of a risk premium, because if you don't, it'll creep in anyway, just in a patchy and inconsistent manner. Over time it becomes "priced in" to the moving average, which is good, assuming that employee instincts are generally valid. Of course, if someone makes the mistake of trying to peg points to time, they're indirectly creating a kind of inflation: Yesterday's "just in case" premium should not become today's "everything goes well" baseline. |
| |
| ▲ | aryehof a day ago | parent | prev [-] | | Its a way to say how long it will take without saying how long it will take. |
| |
| ▲ | tardedmeme 2 days ago | parent | prev [-] | | I'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. |
| |
| ▲ | pydry a day ago | parent | prev [-] | | If you earnestly believe story points are a good measure of productivity then Im afraid you have a lot to learn. |
| |
| ▲ | SlinkyOnStairs 2 days ago | parent | prev [-] | | Almost 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 2 days ago | parent | next [-] | | It'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. | | | |
| ▲ | cdud3 2 days ago | parent | prev [-] | | Amen. 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. |
|
|
|
| ▲ | danaris 2 days ago | parent | prev | next [-] |
| > They're not going to dredge up decade old institutional knowledge Worse—they'll get the people who hold that knowledge laid off, and at least 50% of the institutional knowledge won't be documented anywhere that even could be fed to the LLM. |
|
| ▲ | palmotea 2 days ago | parent | prev [-] |
| > So much of Management (both mid and executive) still considers Software as if it were an assembly line; "We make software just like how Ford makes cars". Code as a product. Which, it should be noted, is the dumbest idea ever. The Ford assembly line makes more-or-less identical copies of the same design. How do you do that with software? The cp command. If someone thinks like that, they probably read some business book and either didn't understand the book, don't understand their own business, or is following some guru who has one of those problems. |
| |
| ▲ | DoctorOetker 2 days ago | parent | next [-] | | Precisely, cars are more-or-less identical copies, at each position along the assembly line its just one of a handful of variants of the step that needs to be executed. Software is less like an assembly line and more like plumbing: Some people design which type of pipe needs to be routed from here to there. The implementor actually pipes the outputs of one function, in a variable, and then taps it off as an argument to another function. Software development is like plumbing really, so a good manager of a pipeworks and plumbing company might actually make a good manager for software companies as well. This is also why its actually not so surprising that LLM's are mastering programming skills, it's essentially just being a plumber, and a lot of people are happy they no longer need to be a plumber. Physicists, engineers, scientists, ... they have much more complicated tasks compared to plumbers, programmers and code monkeys. | | |
| ▲ | AlotOfReading 2 days ago | parent | next [-] | | An assembly line is plumbing too. And just like software, while there are a finite number of variants at any specific time, the plumbing is constantly being rearranged for various reasons. A line won't look the same in 6 months as it does today. Physicists, engineers, scientists, ... they have much more complicated tasks compared to plumbers, programmers and code monkeys.
I've sat next to the industrial engineers designing the lines and MechEs working in CAD. My software job wasn't all that different at a high level. We all wrote requirements, made bugfixes, and complained about the tier 1s. They usually spent more time visiting the lines in Asia/Mexico/Michigan/Canada. I just emailed the factory when I needed to fix something. | |
| ▲ | palmotea 2 days ago | parent | prev | next [-] | | > Software development is like plumbing really, so a good manager of a pipeworks and plumbing company might actually make a good manager for software companies as well. No, wrong again. Some software development tasks are like plumbing, but that misses a lot. Your claim in sort of like saying since the Wendelstein_7-X has wiring, the manager an electrical contractor would be good to lead that project. Plumbers and electricians more or less solve the same problems over and over with slightly different parameters, and because of the repetitiveness, they can do a good job by following (a hefty number) of rules of thumb (the building code). A software developer isn't going to go far just throwing design patterns at a problem (though many bad ones try). | |
| ▲ | QuercusMax 2 days ago | parent | prev [-] | | The plumber who has a robot who can make perfectly measured custom one-off tools and specially constructed piping runs inside your walls is going to have super powers compared to somebody who has to go to home depot and assemble a bunch of PVC pipes or whatever. Just the other day I needed to make a calibration interface for a home automation app (pointing a dumb webcam at my washer and dryer so I can tell if they're done without running up and down two flights or stairs). I just wanted to be able to look at the whole scene and manually pick the ROI to extract and display on my home dashboard. So I asked the AI to build me a stupid little web UI where I can just click to select the ROI center, and what it built me in 10 seconds was perfect for my needs. Was it pretty? Not really. Was it what I would have built myself? Not quite - but it solved the problem I had without me needing to remember or look up how to do all the specifics. | | |
| ▲ | ninjagoo a day ago | parent | next [-] | | > pointing a dumb webcam at my washer and dryer so I can tell if they're done without running up and down two flights or stairs). I just wanted to be able to look at the whole scene and manually pick the ROI to extract and display on my home dashboard. So I asked the AI to build me a stupid little web UI where I can just click to select the ROI center, and what it built me in 10 seconds was perfect for my needs. The machines all beep when they're done. A baby monitor in the machine area will accomplish the same thing :-) But of course the project is much more fun ... | |
| ▲ | tardedmeme 2 days ago | parent | prev [-] | | Have you considered taping a sensor to the light, or measuring the electrical current flowing through the power cord? Both should be a bit more reliable. The idea of messing with mains power is scary at first but with basic precautions it's fine, and I think you can buy current meters with various interfaces if you aren't comfortable. | | |
| ▲ | QuercusMax a day ago | parent [-] | | Why would I buy power meters and mess around with indirect signals that don't measure what I want (how much time is left on the cycle) and instead just tell me whether it's running? I already have an old webcam and raspi I'm not using, and they measure exactly what I care about. | | |
| ▲ | ninjagoo a day ago | parent [-] | | > how much time is left on the cycle Ooh, new requirement! Set timer on phone when setting timer on machine... | | |
| ▲ | QuercusMax a day ago | parent [-] | | Ah, but my washer and dryer love to lie to me and add 20 minutes to the cycle because they're "eco-friendly". And this is mostly to help my wife who has a brain injury and can't remember to set a timer. | | |
| ▲ | ninjagoo 21 hours ago | parent [-] | | > this is mostly to help my wife who has a brain injury Sorry to hear that. Hope things get better. Don't know if your wife's case fits, but the brain has a lot of plasticity; fingers-crossed. > my washer and dryer love to lie to me and add 20 minutes to the cycle We're going to have to assign a business analyst here to capture the full slate of requirements before we start development, i.e., armchair suggestions :-) I don't think agile is working very well here | | |
| ▲ | QuercusMax 17 hours ago | parent [-] | | You see, you're trying to paint the bike shed after I've already built a pole barn for my ATVs. |
|
|
|
|
|
|
| |
| ▲ | Henchman21 2 days ago | parent | prev [-] | | > If someone thinks like that So like 95% of business school graduates? |
|
