Every Dev Team Lead knows (but will never admit) that 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 number of things a developer has to do to find the root cause of a bug can be emotionally crippling, because when you’re debugging, you have to deal with your failures and you keep failing over and over again.
Debugging can become so ineffective that it prevents you from coming up with solutions. Debugging means dealing with a lot of data. You’re trying to find the one thing that is causing the problem – the needle in your full stack. Often, you have a scenario where everything is working fine, and then, suddenly, it’s not. This the “WTF” moment where you have to dive into a large volume of information that can overwhelm any developer. Everything looks fine, but deep inside that pile of data you have to dig through lies a bug. When you succeed, the epiphany is equal parts intellectual and psychological – it’s exhilarating. But it’s only exhilarating because you invested so much focus, emotion and time into finding and solving 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’re 80% done, you suddenly discover that you still have 80% of the road ahead of you to go to find the bugs and stabilize the release. As you enter bug-squashing sprints, the software is so unstable that QA is running wild hitting you with tickets left and right. It feels like no matter how good you are, you are still only the best hamster on the wheel. You keep running up a hill which turns into a massive escalating sh*t storm where QA finds 3 new bugs for each one your team fixes. Your team, being under the bug grind, treats bugs superficially, without getting to the bottom of each bug. Even if they are being thorough, you always have to check in on them, and maybe even push them a little. And nobody likes to be pushed. Then again, if you don’t, QA will find new ways to crush 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 failure” – the team feels like they’re failing you and themselves, so they get frustrated, lose motivation and do even worse.
Being a former developer, you want to shield your team from that feeling of being constantly on edge, like 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 applying pressuring to meet them. You’ll just keep getting caught between a rock and a hard place with one constant on the horizon – it’s only 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 do, however, waste time on 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, or 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, people keep inventing new and wonderful 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”.
Different studies out there show that we spend up to 50% of our time on debugging.
What if you had 50% more time? What would you achieve with an average lifespan of 108 years? What would you do if you had an additional 12 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.
Ozcode Production Debugger
Bridge the gap between finding errors in Production and pinpointing their root cause in code.
Ozcode Visual Studio Extension
Makes local debugging with Visual Studio easier than you dare to imagine.