Skip to content
Home » Build Now vs Build Later: Upfront Design vs Implementation Costs

Build Now vs Build Later: Upfront Design vs Implementation Costs

In my recent podcast episode “Emergent Architecture and Beating the Monolith” I explore the idea that we don’t actually need to beat any monolith or microservices architecture, just get along with the notion that we don’t start or end anywhere in particular and all architecture is essentially emergent.

Following on from that I came across Another Wonderful Martin Fowler Post (AWMFP) called “Monolith First” and I have to smile because, yes, this is the path of least resistance. The corollary of this must be: “just start building something. Worry about what it actually is, later”.

When writing the podcast episode I sketched out a few ideas of what upfront design vs implementation cost might look like. Three models appeared – one where you have no design upfront and just build something, one where you do “some” design in advance and one where you do “lots” of design upfront.

Another concept from the episode is the “Time to First Gotcha” (TTFG) the time it takes you to realise as a project team that you’re going down the wrong track. Replan, rework and move on accordingly. Any rework costs time and money, therefore I examined three fictional scenarios where the implementation is interrupted by a ‘gotcha’ moment where the team realises they need to redesign or completely re-implement.

In the first example, no gotchas we see how the cost is zero, low and medium according to upfront design costs. Eventually, the three paths settle around a notional number of 7k for the project cost.

In the second example, we have a gotcha at 3 months that requires more rework both from a design and development perspective. We see a picture where the line steepens for all three models and the total expense tops out above the previous model.

Finally, we have a double gotcha, at three and six months and the consequent bump of costs above the 10k mark.

I’ve made no attempt here to quantify the actual amount of design. I wanted to show how little it matters where you start, with what level of design – changes mean you’re always going to incur extra costs when you change your mind.

The next question is – does better discovery lead to better project outcomes? How would you quantify discovery in this case and how would you know the outcomes you need?





Discover more from Richard Bown

Subscribe now to keep reading and get access to the full archive.

Continue reading