It’s Dangerous to Go Fast – But We Cannot Afford to Go Slow

For some reason, I often find myself writing MVPs and small POCs in attempt to justify a larger development project, verify a design, or otherwise have to deliver something working from end-to-end in a crunch. And I’m pretty sure this is familiar to most programmers.
To be brutally honest, in such tasks many corners get cut. Ugly code gets created, and bad design gets its chance to survive. Depending on the scope and speed more non-trivial parts of the system are either dismissed or simply forgotten due the lack of time or attention. And finally, as you approach your final moments before your deadline, you understand you either have to start making more radical choices, or fail to deliver.
And the next part of the story we all know:
”Breaking News: Excellent Software Delivered to Client on Time. Great Results. Great People. Great Company.”
You boast in the spotlight, and let the paparazzis get their money shots. Managers pat your back, and returning the favour, you remind everyone how great the whole team was. Everyone tells how everybody just worked together so tightly to make their best efforts in a such a crunch. Great results come from true dedication. And you feel alive for making such great work.
But what often follows, could hardly be less appealing.
You get back to your station. Away from the blindingly bright spotlights, the harsh reality quickly kicks in.
”Which corners did I cut?”
You start scraping through your tech notes and design sketches. You recall hard-coding a thing or two and make a couple of notes about removing them. You remember forgetting to wire up those unit tests to your CI pipeline and recall eventually commenting out a couple of those tests in a hurry while refactoring for a quick fix.
Once you barely get your stack back up and running and start working on all those points, new feature requests flood in with another deadline.
You need to make this engine better, while it’s running. And no, you cannot stop or break it – even knowing that you made it yourself.
Something that you designed – even given and knowing the scope of its current design and all of its limitations – has been engineered into existence. You probably still remember all those small design decisions you made, and recall making your architecture bleed from all those small paper cuts you got while cutting the corners in the attempt to fit the scope of that virtual time box.
However, what was delivered likely doesn’t fully display the extent of the debt taken. Sure, there may be bugs in the UI. The backend may be slow and sometimes things go bust with customers getting 404 or 500 in favour of their preferred reports and responses. But truly, the whole extent of the known and unknown technical and design debt taken rests on your shoulders alone.
But customers are happy. Or at least they don’t mind the problems that much. And so does the work of your labour persist.
Status Quo
As time passes, memories of the original, hugely successful and productive design sprint, MVP, POC or whatever it was called, fades into history. Slowly, everyone adjusts to the new reality where even the smallest of changes require a process, and things evolve in a slow and yet somehow appealingly predictable fashion. And let it be known there were and there are dragons: time and repetition of bug issue tracking process over and over again, has ironed out the biggest wrinkles of the architecture and lacking design and technical documentation. Someone has probably even opened a wiki or FAQ pages for catering the endless hunger for more knowledge on common issues and troubleshooting requests.
But at some point, someone, and for some reason, summons the courage for that profound, perhaps existential question:
”Does it have to be this way?”
And initially, there will be resistance. Safety, and the need for comprehensive manual testing along with various other quality assurance rituals are cited as reasons for lack of change. Remarks on previous catastrophic issues on earlier large changes will be made and quoted as reasons for trying to keep the current production as stable as possible. Change whatever you want, wherever you want, as long as you make sure the production doesn’t break. And nothing, nowhere is touched.
But seeds of an eventual rebellion have been planted. Questioning leads to design discussions. And design discussion leads to spec. Spec leads to prototyping. And prototyping leads to hate of the status quo.
And so a new vision is born.
A New Hope
At this point, rebels of the status quo have secretly worked on their pieces of new design and eventually gather for a full, frontal assault. Managers, product owners and other stakeholders are involved and exposed to these new, and fresh ideas. Bold statements on the goodness of this new riskier design are given. And, along with it, endless possibilities and effectiveness of this new world is envisioned.
And eventually, permission for pursuing this risky yet potentially highly rewarding project is given.
Finally. Finally, you get the go ahead for the ultimate new design. Finally, you get to repair all the damages caused by the earlier lack of time, resources and knowledge. Finally, you get redemption for all the technical debt you took last time.
You clean your workspace, initialize a new project and prepare for a new, more perfect start.
But just as you begin writing your first lines of code, you hear the familiar voice calling over your head:
”Not that it matters much, but just that you know we will try to avoid taking any large risks this time.
So if you could just start by getting this to work quickly for next months steering group meeting, we could give you more input. And only if it works by then, we will see if we could quickly get new customers onboard with these new features you proposed”
And you pause for a moment.
You close your eyes for a moment and slowly inhale. You hold your breath for a while and slowly exhale letting your shoulders drop and relax yourself a moment.
And knowing where you are, you grab your keyboard. You grab it like the sword you’ve been mastered to use, and start hacking through yet another jungle of invisible obstacles.
Knowing it is dangerous to go fast. And knowing that you sometimes just have to.
Did you find any familiar themes from the story? Feel free to add your thoughts and comments below