In “Art & Fear” David Bayles tells a pot-making anecdote with profound meaning for software engineering:
A pottery teacher split her class into two halves.
To the first half she said, “You will spend the semester studying pottery, planning, designing, and creating your perfect pot. At the end of the semester, there will be a competition to see whose pot is the best”.
To the other half she said, “You will spend your semester making lots of pots. Your grade will be based on the number of completed pots you finish. At the end of the semester, you’ll also have the opportunity to enter your best pot into a competition.”
The first half of the class threw themselves into their research, planning, and design. Then they set about creating their one, perfect pot for the competition.
The second half of the class immediately grabbed fistfuls of clay and started churning out pots. They made big ones, small ones, simple ones, and intricate ones. Their muscles ached for weeks as they gained the strength needed to throw so many pots.
At the end of class, both halves were invited to enter their most perfect pot into the competition. Once the votes were counted, all of the best pots came from the students that were tasked with quantity. The practice they gained made them significantly better potters than the planners on a quest for a single, perfect pot.
Quantity + Quality
In many ways this anecdote feels counter-intuitive when you first hear but pay careful attention. Does it not resonate with a kernel of truth too?
Operational excellence (TPS, Kaizen, Lean, Agile) make ample use of this principle. Frequent, many and short delivery sprints to keep learning and delivering. Frequent and smaller production batches just-in-time to avoid over-stocking inventory and reveal issues.
Some of us have read about Malcom Gladwell’s research on high-repetition expertise building (the famous “10’000 hours rule” to acquire mastery level in anything).
And yet for all intents and purposes, most of us are somewhat under-appreciating this. We do not know, what we do not know.
We think intuitively we can set the “fulcrum” between quantity and quality, as if it were always a linear trade-off. In truth, we near-systematically overplay “quality” and upfront planning as ideal and deserving our total commitment, whilst near-systematically underplay “early prototyping/testing”.
You do not know what you do not know.
You do not realise what you are under-doing that would deliver greater outcomes, earlier, more economically.
You do not realise what you are over-doing, and what set of snags, failures, under value delivery and friction come with it.
The hidden costs of over-engineering; under-prototyping
Over-engineering can be a tenacious challenge. It often comes dressed as a wolf, in the sheep’s clothing of doing “a proper job”, making it particularly hard to balance.
It can be a psychological attitude, a cultural belief, or occasionally a political tool.
No one in any team wants to be the guy or girl who does sloppy work, so we all have a natural slant towards over-engineering. Or to agreeing with whoever who talks loudest or longest about “quality”.
If anyone ever wants to stop a project for political motives, few things will be as brutally effective as declaring that current delivery reflects poorly on the company. To describe any one element not entirely fleshed out as “shoddy”. Once expressed subjectively like that, the temptation will be to pause or can the project.
We have all seen someone over-engineering something so much that all currency is lost. Worse, over-planning and over-engineering lengthens timelines, makes organisations less change ready.
Over-engineering bring its own set of complexity with too many cooks ruining the broth, collapsing the initial vision into complicated entropy, never refreshed by real-life feedback.
Finally, and possibly most importantly, over-engineering is a never-ending source of internal friction. It often pits the over-engineer against colleagues who are often even more committed to their users, and their organisation, but who can intuit that this is just not the best way to engineer.
Over-engineering and under-prototyping are a cultural challenge for organisations
Over-engineering and under-prototyping are more prevalent in larger organisations, than in start-ups. And this is a clue here as to why:
- Start-ups tend to embrace a more transparent, less political communication. Where “radical candour” is often practiced. Where everyone is, to a point anyway, “in this together” removing some friction and politics. Where someone can say “I think we are over-engineering” here without fear of being laughed out of town. It matters to all.
- Start-ups do not have the “fat” of larger organisations, they MUST align as quickly as possible on user outcome and user value delivery. To convince their VC. To extend their “runway”. They have less economies of scales, less branding, less historical clients, lower marketing budgets, etc.
To start-ups, researching and testing what feature delivers the most user value is essential.
Their vision is only as good as what the market feeds back. Nimble they can pivot faster, chisel their next release and tweak their Why if they identify a large pool of untapped market value in their space.
“The only way to win is to learn faster than anyone else.”Eric Ries – The Lean Startup
They do not have the luxury of accommodating the drama from Larry from sales who hates Jen from accounting and so will stifle any planning for the new internal reporting software. Start-ups are brutally effective, those that hang around at all anyway.
It is all coherent with Lean Start-up also, as expounded by Eric Ries, in the book of the same name.
“We must learn what customers really want, not what they say they want or what we think they should want.”
“Fail fast, fail early”
“Reading is good, action is better”.
The idea here is to use quick iteration and testing to validate assumptions and re-align as quickly as possible. Controlled, limited “failure” as a strategic tool to learn precious real-life feedback and develop value/avoid waste, as quickly as possible.
True Agile helps managing over-engineering
True Agile is a natural ally to manage over-engineering smartly. Quick iteration and feedback loops is a natural antidote to over-planning and over-researching/engineering.
In the Agile manifesto it is written plainly that the key measure of success in software engineering is working code. There is a reason to that.
Working code is less pretty than fully/over-engineered code but it is also extremely faster to develop. In 10% of the time required doing something perfect, “working” code can a) deliver early value to the user earlier b) provide insights to the project team that they can integrate immediately in their next iteration. And then the one after that too. And then again with a new generation of learning at each iteration, a new refining of the vision, a new discovery of unseen contingencies, earlier, and cheaper to fix.
This is now generally accepted to the be the smart way to engineer, as opposed to “Big Design Up Front” or “Waterfall” methodology where all is planned in advanced and delivered sequentially in massive blocks. Slow to change, slow to pivot, poor at hitting user value in moving markets. Wasteful.
Prototypes & Mock-ups: How to adopt them
Prototypes at least have a very “engineery” feel, something tangible. It can still be a tough sell in larger corporations. The idea that the initial vision is possibly not perfect, either in planning or design or operational capability, is not always a popular suggestion. The idea of spending even just a few hours doing a prototype is often seen as a “waste” of time, still.
So it is important as for any change project, to plan a bit how to gradually effect the culture and the conversation.
As a rule of thumb, a good start is to:
- Evolve the conversation gradually towards a higher awareness at least, that some projects can be over-engineered. That over-engineering can be a political tool. That over-engineering and under-prototyping can have deeply damaging consequences.
- Engage executives and key operational leaders around the importance of prototyping, the value of mock-ups and user story maps. Have a few vivid examples of competitors success or internal success stories, make the discussion concrete. Move away from prototyping being something “nice to have but like so many other things” to something essential to better, faster innovation.
Prototypes routinely flush out some enormous assumptions that have been made during planning stage. The waste they avoid can be astonishing. This stakeholder did not realise that her team was responsible for this activity. That one suddenly realises that there are two key contingencies that had been missed.
Mock-ups and prototypes are probably the best way to “fail” safely, do all the learning for only a tiny expense of time. Remove the big assumptions and the big risk so that the front-end of the design process is immediately optimised and incorporate cross-functional feedback as early as possible.