Every dev Team Lead knows (but will never admit): We rarely deliver on time, and we can never fully quantify how much time we spend on debugging. Ask yourself and answer honestly: how much time do you and your team spend on debugging? Besides being time-consuming, the amount of things a developer has to do to find the root cause can be emotionally crippling: when you’re debugging you keep trying to deal with your failures and it keeps you failing. Debugging can become so ineffective that it keeps you from coming up with solutions. When you’re debugging you’re dealing with a lot of data. And you’re trying to find the one thing that is causing the problem – the needle in your full stack. Often times you have a scenario where everything is working fine, until it’s not and you try to dive into a large volume of information. More often than not, developers are overwhelmed with the amount of data and information that needed to be taken into account – we call them WTF moments: everything looks fine but deep inside that pile of data lies a bug. When you succeed, the epiphany is equal parts intellectual and psychological – it is exhilarating. But it’s only exhilarating because you invested so much focus, emotion and time into trying to find and solve the problem. So let’s ask that question again: How much time do you spend on debugging (collectively)? In a day? A month? A year?
The 80% After the 80%
Agile methodologies mean constantly pushing out new deployments so you can get feedback early, but just because you’re agile doesn’t mean you’re fast: when you finish 80% of the work, you discover or know you still have 80% of the road ahead of you: find the bugs, stabilize the release. As you enter bug-crunching sprints the software is so unstable that QA are running wild hitting you with tickets left and right. It feels like no matter how good you are, you are the best hamster on the wheel. You keep running up a hill which turns into a massive escalating sh*t storm: QA finds 3 new bugs for each one your team fixes. Your team, being under the bug grind, treats the bugs superficially, without getting to the bottom of each bug. Even if they’re not – you always have to check and micromanage them. And nobody likes a micro-manager. Then again if you don’t, QA will find new ways to crash your soul with new bugs. You’re damned if you do, and you’re most certainly damned if you don’t.
The Circle of Fail
It’s what I call “The vicious circle of fail” – The team feels like they’re failing themselves and you.
Being a former developer, you want to shield your team from that feeling of being constantly on edge, the building is always on fire. You also know that the routine of assigning your team a “critical – feature – du – jour” every other day is deeply flawed just like swamping the team with unreasonable arbitrary deadlines and pressuring them around it. So you’re constantly caught between a rock and a hard place with only one constant in the horizon – it’s going to get worse.
So to answer the question:” How much time you spend on debugging?”
Zilch. Nada. Diddly-squat.
You spend zero time on debugging.
You are however wasting your time debugging.
When you are debugging, you waste a lot of time. Think about it: while you’re debugging, you’re not crafting a fabulous new feature that will delight customers and provide them with real value, you’re not refactoring to improve the quality and maintainability of the existing code base. All you’re doing is banging your head against the wall, trying to fix a mistake.
And the real-shocker? Nobody measures it, nobody owns up to it. In a performance-based world, with cults of efficiency, everybody keeps on inventing complex formulas to cover their corporate butts. Agile is just a sophisticated system for removing responsibility. It’s like saying “oh the elephant is so big (if you admit there’s an elephant) so let’s make the room bigger”.
What if you had 40% more time? What would you achieve with an average lifespan of 116 years? What would you do if you had an additional 9.6 hours a day? I can tell you one thing for sure – It probably would not be sprint planning.
Confronting these truths and shifting the way we perform and measure our performance is the only way to deliver better code faster. It’s time to stop fixing errors and start making sense of your code in the first place.