4 ms·

The slicing is the difficult part. Especially when there are so many dependencies, so many things are intertwingled, you need both back-end and front-end and m

The slicing is the difficult part. Especially when there are so many dependencies, so many things are intertwingled, you need both back-end and front-end and maybe migrations and configuration to support this new thing. A legacy system has to work with an API, and there are permissions and data structures and so on that need to be right just for the bare minimum. There's only so far you can go with feature flags and "work in progress" changelogs. Plus having to beware shattering things into tiny pieces and then having to puzzle them all back together at end of sprint with code conflicts and tests that now fail when you combine things and maybe missing or incompatible bits that would've worked better if at least these pieces had been built wholistically. You can only get so small before you're actually making more work and more potential for inconsistencies and delays. All the tech stuff we do is relatively much easier in comparison to figuring out how to slice it well. That's the perennial challenge. Design, optimization, security - all are challenging topics, but none nearly as challenging as slicing things optimally.

cheeseface 3y ago
Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-term throughput and more developer flow time, but less collaboration, knowledge-sharing, and predictability. You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2. For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).

cheeseface 3y ago

Optimal slicing is indeed a hard problem, since what is ”optimal” also depends on what you’re optimizing for. Bigger slices more easily lead to higher short-term throughput and more developer flow time, but less collaboration, knowledge-sharing, and predictability. You meantioned ”sprints” so sounds like you’re working with something Scrumlike? I worked in Scrum teams for ~5 years and have now worked with Kanban for the past 2. For me, Kanban has really solved much of the ”puzzle everything together at the end.” Instead of sprints we structure our around stories (goal of the original scope is ~2 weeks). Before we start, we slice the work inside the story into less than 1 day tasks (or as small as feasible). This allows us to have a high-level plan on the APIs, migrations, frontend, and backend work. Each story can then have 2-4 people working on them (depending on the level of ”natural concurrency” the tasks offer).