8
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 31 May 2026
8 points (83.3% liked)
Experienced Devs
5627 readers
3 users here now
A community for discussion amongst professional software developers.
Posts should be relevant to those well into their careers.
For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:
- Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 3 years ago
MODERATORS
I'd be a bit careful with the assumption that a good enough overarching doc stops the create feature getting rewritten when bulk-edit turns up. In my experience it usually doesn't. Trying to design the whole thing up front so the later feature drops in cleanly is the old big-design-up-front problem, you end up guessing about the part you haven't built. souperk and doo are right that it's cheaper to expect the refactor and keep the steps small.
What the doc is genuinely useful for is the boundaries. Write down what the create part is allowed to depend on and hold it to that. If create only ever goes through a repo abstraction and never reaches into provisioning internals it doesn't need, then bulk-edit comes in as a new module against the same boundary instead of a rewrite. When you do find the second feature forcing changes deep in the first, that's nearly always the first one having coupled to something it never needed, and no amount of spec detail up front would have caught it. So I'd keep the design phase you're after, just spend it on those boundaries rather than trying to predict the features you haven't specced.
I wrote the boundaries idea up here if it's any use: https://prickles.org/tenet/bounded-contexts/A6
Wow, this is really interesting! Thanks for the insights, and the write up!