Why Do We Put Bugs in Our Code?

February 1, 2013 — Posted by Al Shalloway

The man who does not read good books has no advantage over the man who can’t read them.  – Mark Twain

An associate of ours recently told us that he wasn’t aware that we were one of the top technical training companies in the world.  Heck, he didn’t even know we did technical training.  We actually started out as a technical training company doing courses on object-oriented analysis and design, design patterns, refactoring, and TDD.  We’ve since expanded to include Acceptance Test-Driven Development, emergent design, essential skills for the agile developer and more.

I guess this lack of awareness has happened because I have so much passion on the misinformation that is so widely present in the Lean-Agile space I've been really focusing on that.  In a sense, I've felt we have the technical space handled since there is a very solid consensus on what it takes to write solid code.  However, even there, the number of people following these known guidelines is a very small number when compared to the number of developers out there.

So, to help close the technology gap in code, particularly in software programming methods, I’ve decided to write a blog series on how we can improve code quality – dramatically – and without a huge effort.   I’m going to begin at the beginning so to speak.  Here goes…

"What was I doing when I put this bug in my code?" I first asked this question almost 3 decades ago. That sounds like a long time, but in a funny sense, the longer time was the 14 years it took me from writing my first bug until I asked that question.

How can I remember that I asked this question in 1984 (I wrote my first code in 1970)?  Because I still remember my twofold reaction to it. First, was a realization that I was putting the bugs in my code.  I noted that both I and other programmers talk about bugs as if gremlins are putting them in there – “hey, I found a bug” speaking as if I hadn't put it there. Many times this bug was in code I alone had written.  Immediately after this realization that it was, in fact, me putting the bugs in, I remember asking myself “how can it have taken me 14 years to ask this question?”  I mean, it wasn’t like this was only the 2nd or 3rd time I’d written a bug in that time (I wish)..

I’m not particularly fast at times but it struck me as odd that I’d been doing something I didn’t want to do literally thousands of times and had never asked myself “why?”  I had, of course, asked myself how I could be a better programmer and what were good programming techniques and many other questions.  But “what was I doing when I put a bug in my code?” had never been asked by myself to myself.  I felt pretty stupid, to be honest.  So I asked other people what they had been doing when they put bugs in their code.  Nobody at the time I knew had ever asked themselves that question.

I remember that for the next several months whenever I found a bug I looked at what had caused it and wrote the answer down.  Before long I literally had pages and pages filled with many reasons.  I started to organize and group them, and basically rediscovered concepts such as cohesion, coupling, redundancy and more.  Sometimes the reasons were as simple as being distracted or not using good variable names and getting confused.

The point is, while learning good coding methods and all that is great, looking at how we are being and what we are doing when we write the bugs is essential if we want to improve.  I’m assuming, of course, that you are not trying to write bugs as in this Dilbert.  This introspection was the beginning of the road for me to truly understand what writing solid code required.  Sure, I’d read books before this but, writing what you should be doing and understanding what you are doing are two different things. .

I would suggest that many of the bugs we write are due to small decisions we made earlier that set us up to write the bug.  For example, a simple copy and paste of a couple of lines to save the time of making a function sets us up later to change these lines in one place when needed but not the other.  In other words, not only do we put bugs in our code, we set ourselves up to do so.   

In this blog series I’ll point out ways we can make small decisions that will improve the quality of our code and not set ourselves up to degrade it.  However, I'd suggest the first step is to start being a little introspective and look at why you make the decisions you do.  I have seen a huge disparity between what developers know what to do and what shows up in your code.  Why is that?  It's an important thing to know. If you want a glimpse of where I’m headed, here are some resources. 

BTW: I'll paraphrase Mark Twain's quote above for us developers - "he who understands good code but doesn't write it is no better than the person who does not understand it."

Al Shalloway
CEO, Net Objectives


Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban