By Tjaard du Plessis, Synthesis Head of Digital & Emerging Tech
Here be Dragons!
There's something about that moment when you go: File > New. Together with the beauty of the blank page, the nothingness also invokes, fear. Fear of uncertainty. At the start of a project is when we know the least. Surely, we can't be building software in such a state of unknown? What is needed is a way to eliminate uncertainty before we start, right?
The traditional and maybe most intuitive approach is to analyse before you start, to carefully map out a plan. The tension of uncertainty will be removed and out pops a cost, a time and a nifty Gantt chart. A stock take at this moment usually reveals a stack of documents and three months’ worth of invoices.
Before the ink is dry
The traditional approach works. Wait... what? Time to quote Game of Thrones: "You know, my brother once told me that nothing someone says before the word "but" really counts" ~ Benjen Stark.
The traditional approach works, but... only if nothing changes. And as we all know, before the ink on that shiny functional spec is dry, the dragon of change is set loose, and with its swooping wings lays waste to your analysis. Before you armour up though, even if we could wield the sword and slay the dragon of change, the traditional approach to analysis has yet another detractor. Warning, the following might evoke painful memories, parental guidance is advised.
Enter the dragons
The three months analysis phase has just completed, it's time to transform ink into code. With the safety of the functional spec beside you, you start churning out working software. And then, that iceberg moment. "This won't work according to plan? Didn't analysis erase all uncertainty?" Your minds picture of the project manager's worried face is enough to convince you to park this thought somewhere between "not my problem" and "where's the coffee". You balance a hack with sticking to the spec and pass the code on to be tested, only to discover another iceberg, argh, more uncertainty, how is this possible?! At least there's still loads of time before the demo and by then there will be no questions, it will be exactly what everyone wanted. Hmm... That's not quite how the story ends, is it? Coding, testing, demo and the whole act of delivering software always brings with it, more learning.
How to train your Dragon
So, on the one hand change renders our analysis waste and on the other, valuable learnings emerge only when it's too late. But both change and learnings aren't evil! They, and their fiercer brother, uncertainty, can be trained!
Stop being afraid. The solution is easy to execute, it's the change of mind that's hard to accept. The traditional mindset divides delivery into phases, allowing learning only in phase: Analysis. I'm proposing that coding, testing, demo and yes, normal stock standard analysis too, are actually all great tools for feedback and learning and you need all of them to slay the dragon of uncertainty. Therefore, start isn't something you do after analysis, start is coding, testing and demo. It's time for a change of start. Get rid of phased thinking, embrace uncertainty and simply... just... start. Eventually you'll find that building without analysis isn't waste, analysis without build, is.
