cross-posted from: https://programming.dev/post/51247328

I use speckit, and while I like the spec/clarify/plan/task/analyze/implement loop (although it can get a bit overwhelming at times), I don’t like that I have to start with writing a spec and implement it to begin with. I am looking for a more of a design phase before the spec phase, where I can talk about the overall application architecture, and then start writing specs for implementing pieces of it.

For instance, let’s say I want to build a github repo provisioner that 1. creates repos with desired setup, and 2. bulk edit repos with secret updates, yaml updates, etc. I don’t want to build both the features at the beginning. I want to first build only the create portion, and then do the bulk edit feature later on. With speckit, I can do this by only telling it to create the spec for the build portion, but later if I want to build the bulk edit portion, the whole application might need to be changed in important places, because it wasn’t a ‘planned’ feature when it was first designed. I want instead to have a design phase where I describe and maintain a doc with the whole application, and when I start the spec for the create portion, the agent can understand that this create portion is only part of a bigger application and can design/implement the create portion accordingly.

Have you come across a situation like this? how do you handle your big applications? Please advise.

  • nark3d@thelemmy.club
    1·
    1 day ago

    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