←back to thread

The quality of AI-assisted software depends on unit of work management

(blog.nilenso.com)
170 points mogambo1 | 1 comments | 18 Sep 25 13:06 UTC | HN request time: 0s | source
Show context
danparsonson ◴[18 Sep 25 17:25 UTC] No.45292426[source]▶
I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cases for the building arise out of the combination of different elements that were put into it, and usually right near the end of the build. The same is true for basically anything else that we build or create - if you're making a sculpture, do you finish working on one leg first before you move onto some other part?

Features are vertical slices through the software cake, but the cake is actually made out of horizontal layers. Creating a bunch of servings of cake and then trying to stick them together just results in a fragile mess that's difficult to work with and easy to break.

replies(9): >>45292458 #>>45292564 #>>45292986 #>>45293703 #>>45294397 #>>45296892 #>>45297236 #>>45298940 #>>45307633 #
ath_ray ◴[19 Sep 25 07:36 UTC] No.45298940[source]▶
"Unit of work" here is the unit for software delivery, and it can be decoupled from how any individual developer plans and executes whatever software they are delivering.

Product requirements are a hypothesis for creating business value, and the only way to test that hypothesis is to actually demonstrate a slice of that value in a way that's legible to all stakeholders involved.

This post is a nice articulation of this: https://blog.nilenso.com/blog/2025/09/17/the-common-sense-un...

replies(2): >>45299303 #>>45299949 #
danparsonson ◴[19 Sep 25 10:17 UTC] No.45299949[source]▶
That's the point though, thinking of delivery in terms of slices of business value naturally leads one to break application development along those lines. It's very convenient for the stakeholders to see progress mapped out like that, but it tends to lead to fragile and poorly-architected systems that are difficult to change in the future (and therefore not lower-case A agile).
replies(1): >>45302394 #
1. sriharis ◴[19 Sep 25 14:59 UTC] No.45302394[source]▶
Slicing a cake across layers is about prioritising value and mitigating the risk of building the wrong thing. Most product and feature requirements are hypothesis for creating value, unless that hypothesis has already been validated.

> It's very convenient for the stakeholders to see progress mapped out like that It's important for the business to validate product value. This is not just progress anxiety.

Crafting software to perfection is ultimately a waste if it doesn't provide value to the business or customer. If we are sure we're building the right thing, we can risk more, and spend more of our time building the thing better. Build scrappy first, build confidence in value, and then craft to perfection.

The slices of cake aren't built in isolation. Every time a slice is being worked on, it is integrated back. The cake analogy falls apart here, because cakes (and houses) aren't nearly as malleable as software. We have opportunities to refactor it every step along the way, and change its shape. Yes, sometimes we refactor independent of business value, and I think that's essential too. I don't think the idea that's presented is to have absolutely every slice be vertical, and business / customer facing.