←back to thread

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

(blog.nilenso.com)
170 points mogambo1 | 2 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 #
galbar ◴[18 Sep 25 17:36 UTC] No.45292564[source]▶
My take on this is that, from a SW development POV, user stories are not the right unit of work. Instead, I treat user stories as "Epics". Stake holders can track that Epic for progress, as the unit of work from their POV.

Internally, the team splits Epics into "Spikes" (figure out what to do) and "Tasks" (executing on the things we need to do).

- Spikes are scoped to up to 3 days and their outcome is usually a doc and either a follow-up Spike or Tasks to execute.

- Tasks must be as small and unambiguous as possible (within reason).

replies(1): >>45299904 #
1. danparsonson ◴[19 Sep 25 10:09 UTC] No.45299904[source]▶
Well OK, but that's just the same thing with extra steps.

The point I'm making is that there are large cross-cutting concerns that shouldn't be sliced up by feature, but rather that the features should arise out of the composition of the cross-cutting concerns.

A single user story commonly requires the holy trinity of UI, 'business logic' and data storage, and my contention is that it's more efficient and robust to build those three layers out holistically rather than try to assemble them from the fragments required for all the user stories.

replies(1): >>45301673 #
2. galbar ◴[19 Sep 25 13:50 UTC] No.45301673[source]▶
Our job as SWEs is to convert the vertical slice of functionality into something that fits well and robustly in the various technical layers that need to be touched.

The process that I outlined above explicitly creates the space for SWEs to consider the wider implications of the required changes in the architecture and make robust.

Part of that is understanding what the roadmap is and what is the product vision in the mid term, so that the tech layer can be built, step by step, towards what fits that vision.