2 ms·

I do much the same kind of development. Document the design choices you made and why. That's it. That's your answer. If anything, spend even less time worry

I do much the same kind of development. Document the design choices you made and why. That's it. That's your answer. If anything, spend even less time worrying about 'proper' abstractions. As you've seen, you'll wind up guessing wrong and making more work for yourself/other future maintainer as often as not. Keep it simple. At some nebulous future endpoint, if a client reaches a growth stage where they are ready to take the next step beyond small-scale prototyping, great! It's a good problem to have. Ignore the code you've written and instead read the history of your design decisions that got you to where you are. Business workflow will have co-evolved, and some of your decisions would now flow differently if re-evaluated. Write down the changes, and there's your rough draft spec sheet for version 2.0.

rlayton2 5y ago
That's a great answer I hadn't considered. Thank you!
amorphic 5y ago
I second this approach. I often find myself in similar situations as OP's, working with a client to understand a complex or ill-defined problem space and developing solutions in an agile way. Neither you nor the client has a (functioning) crystal ball and so all that you can do is make the best decisions that you can with the information available at the time. I've found that documenting Architectural Decisions as Architectural Decision Records (ADRs) helps build a shared understanding and ownership of these decisions amongst all concerned. They also prevent me from becoming bogged down and second-guessing myself: Here are the available options, here's what we decided and here's why. No need to make ADRs overly long or complex. I use this "Lightweight" template: https://github.com/peter-evans/lightweight-architecture-decision-records https://github.com/peter-evans/lightweight-architecture-deci...

rlayton2 5y ago

That's a great answer I hadn't considered. Thank you!

amorphic 5y ago

I second this approach. I often find myself in similar situations as OP's, working with a client to understand a complex or ill-defined problem space and developing solutions in an agile way. Neither you nor the client has a (functioning) crystal ball and so all that you can do is make the best decisions that you can with the information available at the time. I've found that documenting Architectural Decisions as Architectural Decision Records (ADRs) helps build a shared understanding and ownership of these decisions amongst all concerned. They also prevent me from becoming bogged down and second-guessing myself: Here are the available options, here's what we decided and here's why. No need to make ADRs overly long or complex. I use this "Lightweight" template: https://github.com/peter-evans/lightweight-architecture-decision-records https://github.com/peter-evans/lightweight-architecture-deci...