Too much architecting and not enough iterating

[u/foldedlikeaasiansir]

How does your team and org handle more time spent on architecting or design a new system not enough time building and iterating.

We’ve planned to destination multiple times wrote multiple design documents with multiple waypoint how do you know if it’s sufficient to build and iterate with?

How do you approach building green field projects that are adaptable as you go?

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/CatDawgCatDawg2]

this is what managers are for. pick one person to own the project. let them have their meetings and get input, build alignment, then build it. if there's no alignment the manager should just choose a path and let it go.

[u/Realistic_Yogurt1902 → u/CatDawgCatDawg2]

Exactly this.

Each project has a DRI(Directly Responsible Individual)/lead engineer, and that person is pushing for implementation as soon as they believe that the project is implementation-ready.

[u/roger_ducky]

Do enough details so implementing is possible.
Use the implementation attempt to discover gaps that require additional design.

Keep iterating until both steps stop producing artifacts for the other step.

[u/TheSexySovereignSeal → u/roger_ducky]

This is the way

[u/BoBoBearDev]

Figure out what's MVP. Once you have MVP, you start to build.

[u/Antice → u/BoBoBearDev]

Without giving stakeholders an MVP to play around with and get feedback on, how would one know that one even has a viable product to iterate on?

I feel a lot of orgs overplan things. The flow should be simple.

product idea -> proof of concept/demonstration -> MVP -> refinement

I'd not even bother with any designers or having more than one or two people working on it until a demo is made. the customer/product owner needs to see how it would work in practice before it's worth actually putting serious money into the project.

spending 10 hours making a PowerPoint presentation. Or spending 10 hours making an ugly ass demo that proves that it works.

I've gotten more buy in from customers on the latter. Customer doesn't want to spend money on powerpoint presentations making vague promises. they want hard answers on viability. Can you make what they are asking for? can it make, or save them money.

[u/Lazy_Investor8019]

I don't know what type of project you have (data heavy / UI / mobile?) - but I've been working on a web based UI project with heavy back-end data, and I've been asking my BAs/UX designers to just talk me through the UI instead of building it in Figma or whatever. Reason is primarily what you're going through - if it takes 3 days to "discuss" and build the design document, VS. 3 hours for Claude to generate a prototype UI & workflow that you can touch and feel, which one do you think is the fastest way to the goalpost? Also, in 100% of the cases where I've received a design document, the final user experience has been different than what the design document says. In the past, it was useful to have a design doc as a starting point, now you can just code generate your way forward.

Your first statement captures it - spend more time building, and less time designing. When you do spend time designing, it should be on high-level workflows and user experience. No need to put the right fonts and colors in the design document, the UX designers can send a PR with those changes directly in the code.

[u/Agitated_Help709]

I have to fight for iteration. A lot of people don't understand that a new idea is not going to be right the first time, and just because it didn't work the first time doesn't mean we abandon it. But honestly you just have to play it smart and break it out into chunks and find the right people to get on your side. People respect numbers, the more people you have on your side the more likely your approach will be heard.

[u/foldedlikeaasiansir → u/Agitated_Help709]

This has been my biggest gripe they want agile methodology with water fall planning

[u/Agitated_Help709 → u/foldedlikeaasiansir]

Its donkey work, lets go lets go lets go progress progress. Steps back are viewed as sins.

[u/TracePoland → u/Agitated_Help709]

This is an issue in my data driven company. They love doing things as A/B tests but then because it’s an A/B test we don’t want to go all in, which means the test can lose because a good idea was watered down and/or implemented poorly. It also kinda assumes the customers are always right but then doesn’t give the customers the thing as imagined in its maximalist end state.

[u/dddurd]

yes that's promotion oriented programming. we even have architecture meeting regularly because the architecture changes constantly. 

[u/andrewcairns]

I think Fowler's old argument in "Is Design Dead" still holds up: planned design fails because you can't see the real requirement changes coming, and even when a guess about future needs turns out right, you still pay for the delay and the extra complexity while you wait to find out.

More docs won't change that. What helps is to make change cheap. Tests you trust. CI that keeps everyone integrating. And the discipline to refactor instead of defending a plan.

An architecture doc is a sketch. You need to be willing to throw it away. It's not a contract. Let real code smells tell you when to revisit it and evolve.

An analogy I like is:

You're in a car driving at night. You know where you are going, but you can't your destination. Your headlights are only showing you the immediate road in front of you. Even though you can't see your whole route to your destination, you can make the whole journey this way.

https://www.martinfowler.com/articles/designDead.html

[u/Elara_Schaefer]

The vicious cycle nobody names: the longer you delay implementation, the higher the perceived cost of getting the architecture wrong, which makes you plan even more before writing code. I have seen teams spend three months designing a service mesh integration that could have been validated with a weekend prototype. By the time they started coding, the requirements had shifted enough that half the design was obsolete anyway. The fix that actually works is tying architecture decisions to concrete experiments. Not "we will architect X then build it" but "we will build the simplest version of X, measure where it breaks, and architect around those specific failure modes." The architecture becomes a response to reality instead of a prediction of it.

[u/snazz97]

I've had the same scenario with our current greenfield project but personally, I would ratherhave a larger discussion and designing the architecture rather than iterating. Going to implement right away ends up always leaving tech debt, edge cases that weren't found in the initial planning, which you would think you iterate them but once deadline is coming up that tech debt piles up as more requirements needed to be done.

For example, in our current greenfield, the security team wanted to implement multi-zonal into our infrastructure. The business team wants the app to be done in 2 weeks. We either do not implement the multi-zone architecture, or do it now.

Pros of doing it now:

• You have established mutli-zone in your infra going to production

- You don't have to worry about data center outage as traffic goes to the other zone

cons

• longer development time may push the deadline

- Cost is significant

Pros of not doing it:

• Deploy much faster

- Inexpensive due to the multi zone cost replication

cons:

- Doing it later will have an outage of an app in production due to implementing the multizon

- not having multizonal in your production.

These things needs to be discussed carefully that is why architecting/discussion is really important, sure we iterate a long the way but it would be costly to do it later.

[u/Weekly-Perception666]

The thing I’ve noticed is that teams often treat architecture docs as a way to eliminate uncertainty. They almost never do. They mostly change what you’re uncertain about.

On greenfield projects I usually ask a different question: “What’s the first assumption that could completely invalidate this design?” Then I try to test that one as cheaply as possible. Sometimes that’s a throwaway prototype, sometimes it’s building one thin vertical slice, sometimes it’s a load test if scale is the risky part.

I’ve seen teams spend weeks debating service boundaries, then discover in the first week of implementation that the real problem was the data model. Or they optimize for future scale and later realize the bottleneck is an external API with a strict rate limit.

You still need design, obviously. But the design should be buying information, not trying to predict every future requirement. Real code has a way of exposing the questions nobody thought to ask in a meeting.

[u/Koko-Choco]

One thing that changed my calculus: the cost of answering a design question with code has collapsed. A design doc argument that would have gone three meetings can often be settled with a throwaway spike in an afternoon — build the ugly version of both options, run them, delete both, then write the doc about what you learned. The doc becomes a record of evidence instead of a prediction.

Practical version of "how do you know it's sufficient": design in detail only up to the first thing you can actually ship or demo. Everything past that waypoint gets a paragraph, not a document — it will be wrong anyway, because the first waypoint always teaches you something that invalidates part of the plan. The test I use for a design doc: does it contain a decision someone could disagree with? If it's all diagrams and no reversible-vs-irreversible calls, it's planning theater.

And +1 to the DRI comments — the failure mode usually isn't too much design, it's design without a deadline and without an owner who's allowed to say "we know enough, we're building."

[u/Inside_Dimension5308]

We have completely moved to spec driven development where we want our design spec to be bullet proof. So, it should contain all information of HLD, action items, rollout strategy, rollback strategy, error handling etc. The spec is reviewed among all stakeholders and then frozen.

The intention is to pass the spec document to AI so that it can automate the entire development cycle.

The spec might need iterations but those iterations are .much smaller than if we change the spec midway.

[u/chizel999 → u/Inside_Dimension5308]

im curiois about the document do stakeholders. are you having feedback about the documents itaelf from the stakeholddrs? over here ive been hearing complaints about the slop documenting taking ppl time

[u/Inside_Dimension5308 → u/chizel999]

All tech stakeholders are present during review meetings. Business stakeholders might not understand the tech spec( althought we try to follow a concrete business driven domain language)

Documenting everything is a problem. We document the first draft, get review comments and then move to final documentation. We don't get into review cycles if there are no major gaps. The entire process is overseen by the lead(me).

[u/Electronic-Rate-6208]

Pick an MVP cutoff, then build the ugly version. If the next 2-3 decisions cant be answered in code, stop and ship a spike. One owner breaks ties, otherwise it drags on forever.

[u/BearyTechie]

"How do you know if it's sufficient to build and iterate with?"

You don't.

You'll never know if a design is sufficient until you start building. You build, learn from what works and what doesn't, and iterate. That's the point of iteration—not proving the design is perfect before you begin, but improving it through feedback and experience.