A few years back, I was asked to work with a team that has worked on an uneasy task for over a year. They were to outsource maintenance and expansion of business-critical software. Interestingly, they took it over from another supplier which, clearly, had no idea how to work on such a product. While developing new functionalities, they were fixing legacy bugs. Being honest, they did create quite a few of their own. It’s just how it is, when you code, there are bugs. On top of it, there was the client’s product owner, struggling to tie lose ends. All the fun you could have, as I thought.
Then one day, there was a face to face meeting.
Client stakeholders swarmed on the team. Product owner. Chief architect. Quality manager. If you can think of a cliché corporate role, they were all there. Countless hours wasted, in a manner just as inefficient as big stockholders owned organizations are legendary to be. What a shame.
There was a bright spot then. The bugs. There were lots of them. Hundreds. With merely fifteen people to deal with them, the supplier had to continue working on new functionalities. While creating new bugs, because that’s just how it is. There was a whole one hour long meeting dedicated to the bugs, which I had opportunity to participate it.
Now, it is worth to say that I did have some experience with bugs before. First time I became a manager, I was working in maintenance, with the boss that I failed to work with properly (my fault) and twenty people worldwide. Each of them hated it. Then, first time I became an Agile Product Owner, was also in maintenance, with up to four teams that I had to somehow balance.
Finally, years earlier, I did some of this stuff myself. And we’re talking hardcore 1970s style assembly code patches. Both sweet dream and a beautiful nightmare.
Point is, I had some solid experience on it.
So, while on the meeting, with charts and statuses flying all around, I asked just one question. “Do we know where all these bugs come from?” The response was mesmerising silence, kind of which you only see in action movies just milliseconds before someone cuts the red wire, or the blue one.
It did take me a while to explain why I asked this question. Why it is essential to get to the root cause of each new bug. Why it is necessary to just pause for a moment, analyse, share the findings, and LEARN. That’s how I was trained. Back in assembly code days, I did send several e-mails to the whole team of over twenty people explaining things I did wrong and why. And each of these people, regardless of their experience, did the same.
The software and hardware were close to being called legacy. The upgrades were painful, with simple addition of compiler optimizations ruining all the best practices we’ve had. Then again, when we made errors, when we introduced bugs, they were always new. We hardly ever did the same mistake twice.
These twenty people were one of the most highly trained teams I’ve ever worked with. Chapeau bas, guys.
Fast forward several years to the meeting. Oh, my words weren’t easy. They shed some light on client’s quality manager activities or rather lack thereof. On the other hand, that’s exactly what I was paid for. Based on my experience, I seriously expected everyone to just agree and say “Okay, let’s get to these bugs then”.
Well, it didn’t work out like this.
I was banned from meeting any representative of this client forever. Because, bugs are part of the business. If you code, there they are. My remarks on lack of analysis were apparently rude. Admittedly, nowadays I would’ve worded them differently. But my banishment was the only tangible result. They did not start any RCA (root cause analysis) on the bugs they had. Inevitably, different people across the team kept introducing the same kinds of faulty code.
Very soon, the bug count rapidly doubled the agreed control limit. Any feature development was halted.
Now, I can accept a lot of things. Hell, I have vices of my own. Numerous ones. If there is one thing that I just can’t live with, it’s the acceptance of substandard work. I do know, that bugs are just part of the business. But I simply cannot imagine one team to do the same thing twice. Well, unless they work for the NASA, as these guys somehow managed to lose a spacecraft (with its crew) in not so bright way. Twice.
Whatever it is you do, you will make mistakes. You can think them over, figure out what went wrong and propagate this knowledge in your team. On the other hand, you can just accept things as they are, keep calm and carry on.
And you know what the best, and the worst, part is? It’s the same for your work and your private life. You learn or you just keep on loosing.
It’s your choice.