Ask HN: New Economics of Software Development Lifecycle | Hacker News Reader

Ask HN: New Economics of Software Development Lifecycle

4 pointsbreckenedge11 comments

Been thinking lately: developing software is arguably faster now with LLMs and agents. (Yes I’m aware of the caveats in making this statement, it’s a premise I ask you to accept for this discussion.)

For years, we’ve been managing projects as if development is the slowest part of the process. Simplified: PMs handoff to Design handoff to Development. Been that way for years in my career basically since Figma took over. But now the Development could be much faster than the Design step. And as often as I’ve been bottlenecked waiting on Design to finalize their work, why not just let the AI+dev come up with the first version of the UI and then replace it when/if an “official” design arrives?

View on HN

That is exactly how I've been working for years, even before AI. The slowest part of everything is sales, so the team has some flexibility in exactly what order to do things when developing features, as a few days of tweaking designs won't actually impact revenue. Devs copy existing patterns from prior features, code things up, and design has time to ask for adjustments before it is released. The longer a product lives, the more patterns already exist that can be copied, the less design needs to come up with new patterns, and the devs can just roll.

So if you have experienced design being a roadblock for years, and you are waiting on Figma for every feature... something is wonky.

Same!

I've worked with a whole lot of PMs who think that we can’t start work on stuff until Design signs off on it because of this misconception that dev is slow.

If you're going to analyze a process you have to look at all of the steps involved, including waiting time, re-work or going backwards in the process/iterating, as well as the time to do the tasks. They all matter in the economics of delivery of working software.

The slowest part is going to be the parts involving humans communicating things to each other and iterating on the requirements and designs and the waiting times in between. The technical coding or generation of assets does not take that much time in the overall process.

Yea, it shouldn't. However many PMs I've worked with over the last decade seem to think that development is the slowest part of the process -- that requirements need to be completely understood and designs completely buttoned up -- before major software work begins, because of this misconception that it's a slow and risky process. Now there's even less evidence to back up that misconception since GenAI can be writing the code in parallel to all the communication.

In my experience the more expensive part of this when actual money is on the table is just the requirements gathering at the very beginning. I am saying that from the perspective of web, military, cloud, and infrastructure.

In order to see this as an actual concern you have to think about it only in terms of outside parties operating via contract. Do not think about this in terms of internal only at the megacorp because the financials are wrong almost every time.

Requirement gatherings and analysis is 90% of the job, software design is the other 90%. Once that's done, it's very easy to code the project. If it's not, take a step back and fix the error you've made at the previous steps (mostly due to a lack of information).

A lot of people think that coding is hard, but that's because they start to code too soon. And then the really hard activities get mixed in and it becomes a whole mess. Also it's quite easy to code, which is why inexperienced people usually rush to do it. Take someone like that and do proper software engineering, and for the first two activities, all you will get from them is a lot of "I don't know".

> Simplified: PMs handoff to Design handoff to Development.

This is the Waterfall process (the bad one Royce said not to do, and the one the DOD went and codified). Don't do this. Use an iterative model and don't use hard barriers between "phases" of development.

Yes well I’d love to but every company I’ve worked at for the last half decade has worked this way.

How else are product managers and designers supposed to justify their existence?

Creating the software is designing it, designers can't beat technical limitations, most of the times.

The slowest part is to prompt based on initial code generation.

Reply on news.ycombinator.com