←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: 0.252s | 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 #
magicalist ◴[18 Sep 25 20:12 UTC] No.45294397[source]▶
I don't think the analogies are that helpful. You are absolutely building the kitchen, the living room, the bathroom as you put in the foundation, framing, the plumbing, the electrical work, etc, or you will get either an unusable house or a very expensive gutting and remodel. User stories are figured out for the house long before any construction begins. House building is well on the waterfall side of development anyways, but at this point, what insight is this analogy yielding?

Call user stories a grouping of work, sure, but I guess I don't see why the distinction matters. Most possible "units of work" will have many cases worth breaking down further regardless of choice of unit.

replies(1): >>45300118 #
1. danparsonson ◴[19 Sep 25 10:44 UTC] No.45300118[source]▶
> You are absolutely building the kitchen, the living room, the bathroom as you put in the foundation, framing, the plumbing, the electrical work, etc

OK, the kitchen and the bathroom are special cases due to the plumbing and so on, so my analogy breaks down a bit there, but the rest of the rooms? They don't crystalise their function until the occupants move in. Maybe I as a builder might assume a certain room will be the living room, and designate another as the master bedroom, but until the owner puts in funiture, they're more or less just empty boxes with power and windows. Most of the 'features' or user stories of the house arise at the end out of the combination of built elements and final decoration. Software is actually a lot like this - take a trivial example user story of creating an invoice. What do you need for that? UI, data storage, comms maybe, some domain logic. Each of those things can (and in my opinion should) be expressed independently, but if you're developing that user story as a single deliverable, then you need to create bits of all of them. And that's what I'm saying - we're building things that naturally decompose into 'horizontal' layers (units of infrastructure), but doing it in 'vertical' slices (user stories), which, to torture my analogy even further, results in uneven flooring, mismatched walls, and untidy structures that get more and more difficult to change over time as requirements change and more builders try to add other slices of building that were not anticipated.

If you want to sleep in the lounge from now on instead of the bedroom, and entertain your guests in the back bedroom, you can just move the furniture. That's a lot more agile in my opinion than the software we commonly build.