Why you must decide acceptable quality early

If you look at the surface of a cycle path and a road they look remarkably similar. The same crushed blue metal embedded in bitumen, rolled flat, white painted lines to designate lanes.

Surface of road compared to surface of cycleway – can you tell which is which?

But the fundamental design and architectural decisions that went into the cycle path versus the road are very different; one is intended to carry cars and trucks and costs significantly more whereas the other is for pedestrians and bicycles only.

Everything below the surface is different: the depth of excavation and preparation of the bare earth, the laying and compacting of base material and the type and size of machines used to do it, the inclusion of shoulders, the schedule for maintenance and repairs and tolerance for defects and damage.

You can’t lay a cycle path and then decide to use it for heavy vehicular traffic as if it were a road even though it looks like a road (though narrower). You could re-purpose a road for cycle traffic only but that would be an incredible waste of money to lay a road if not for use by heavy vehicles.

Likewise with technology, you should make decisions about quality at the beginning and meet those quality criteria at every step.

If you start with relaxed criteria and a lower threshold for accepting software and technology and want to raise the bar later there’s a good chance it’ll be cheaper and safer to throw out everything out and start again.

There are misconceptions that iterative development as done with agile methodologies permits starting with a quick and dirty prototype or MVP and then gradually improving quality whilst also adding features, allowing the design and architecture to somehow emerge organically with little forethought.

This is foolish and will impede your agility; it absolutely is not a practice implied by the Agile Manifesto or Principles, or Scrum, or XP, or any methodology I’m familiar with.

I’ve always said that prototypes are fine, as long as you understand that the outcome is not the code but the learnings. There should be a permeable barrier between project stages so that code isn’t carried across into what is intended to be a production-ready, secure, stable, reliable, usable, and useful product.

Don’t be tempted to dilute and compromise your product with lower-grade code, design, and infrastructure.

Don’t build a cycleway and then drive a 5-tonne truck on it.

If you enjoyed this article please share it with your friends and colleagues.