Historically I have always been baffled when people ask me the question is debugging harder than coding. Being a veteran coder and I think anyone with over 2 years of programming under their belt will easily be able to tell you that yes debugging is harder than coding. However there’s always someone out there challenging this so below I want to break down in detail for you why I believe debugging is harder than coding.
Summary
If you don’t have the time to go into the details of why I consider debugging harder than coding you can glance through the summary list table that I have made below to demonstrate this. I’m going to try to list some reasons which I believe play a major role in the process and affect to some extent why debugging is harder than coding.
| Debugging | Coding | |
|---|---|---|
| Time Investment | Huge | Average |
| Understanding The Code | Difficult | Easy |
| Third Party Libraries | Difficult | Easy |
| Unpredictable Behavior | Difficult | Average |
| Component Interaction | Hard | Average |
| Intermittent Bugs | Difficult | None |
| Lack Of Information | Huge | None |
| Concurrency | Hard | Hard |
As you can see from the table above, pretty much in all categories debugging is harder than coding. I can’t really think of any case where coding harder than debugging but there is one category where I think both are very hard and this is concurrency. I’m going to analyze it below so for now I’ll spare you the details on it.
Time Investment
Any experienced coder knows that debugging can be much more time consuming than coding. I want to go over some of the reasons that I think are important and a lot of people undermine when debugging. It’s often overlooked by programmers and generally when they point their stories in a scrum or kanban board they tend to be generous not allowing time to debug their code for problems.
Lets go over some of the reasons that take significantly more time debugging than coding:
- Debugging requires trying different approaches and experimenting with different solutions.
- It involves testing different hypothesis and experimenting with different fixes, as one solution may not fit it all.
- You need to use an extra tool such as a debugger so it would take you time to set it up, understand how it works and put it in use on helping you find problems.
- Being able to reproduce the bug consistently may take a lot of trial and error as we discussed above.
Understanding The Code
In both coding and debugging you have to deal with code period. Either you are writing it or you are debugging it. The biggest challenge when debugging code however is understanding the code which is most likely not yours. The reason for this is that you are dealing with system libraries, third party libraries, your own code, your colleagues code and potentially other pieces you know nothing about.
When you are coding you are making use of some code but there’s always documentation and information about it, when you are debugging it’s like having to understand all those pieces together and have to put them together in a story. Obviously this is a much harder task to do since the complexity is much higher.
Identifying the specific line or section of code that is causing the error can be difficult. This is especially true when the error message is not clear, or the error occurs in a different part of the code than where it is manifested. Often, the error message itself might not be helpful, and requires a deeper understanding of the codebase to find the actual source of the problem.
Third Party Libraries
It can be difficult to understand how an app library works and what might be causing the problem. This can be particularly challenging if the codebase is large and complex, or if the code has been written in a way that is not easily readable. If the code is written in a language or framework that you are not familiar with, it can be harder to understand the flow and structure of the code, making it more difficult to identify the problem. Just as a reminder if you are using lets say a high level language like Python and it’s using a framework that’s written in C then you need to also know C on top of Python to debug the problem.
This happened to me in a project once that was using C++ templating which ended up making me have to read about templating in order to identify the root cause of the problem. This in my opinion is why understanding the code makes debugging harder than coding.
Unpredictable Behavior
Those bugs can also be caused by side effects from other parts of the code, making it difficult to trace the problem to its source. Sure there’s system tools such as strace and other runtime debuggers which may make it easier bug it’s still a hard problem to solve to begin with. For example, a bug caused by a race condition, where two or more threads are accessing the same data simultaneously, can be difficult to diagnose and fix.
Have you ever heard of heisenbugs? Well neither did I until I run into them and started researching them. This isn’t something you will encounter very often but when it happens you are probably in deep trouble with debugging.
These bugs seem to disappear or change behavior when the code is being observed, making it difficult to reproduce and diagnose. For example, a bug that only occurs when the code is running in a production environment but not in a development environment can be particularly difficult to track down and fix.
When I did security I remember doing things explicitly to the execution of the application if a debugger was being attached to my process to avoid someone understanding the code. While the main reason those bugs arise are not security related or anti-debugging they can certainly happen for no particular reason due to how applications work.
Component Interaction
We briefly touched upon this earlier when we spoke about all the libraries that exist in a compiled application. This however is more related to your application interacting with other platforms or components within your system. For example lets consider the case where your application makes a REST API request and expects a certain response.
If you are coding you have the documentation of the REST API and you know what responses you will be getting. This is a completely predictable behavior that allows you to put the if conditions there and handle it as needed. The situation changes a lot though when you are debugging and not coding it. The main reason for this is that debugging it assumes the rest of the flow will be as predicted. However this will not be as expected based on the flow of your application. In the diagram below I am showing you how things can go wrong and then it will spiral in all the other components associated with that REST API response.
For example a listener may be waiting for that data but also a database controller may be waiting on that data. Both of those components will do a different things with the result for example the database will just store it and the listener may just invoke an event. Since both are different components but both are affected by a single REST API result, now you have to worry about debugging both.
Intermittent Bugs
Intermittent bugs are bugs that only occur under certain conditions and can be difficult to reproduce and diagnose. For example, a bug that only occurs when the application is under a heavy load or when a specific user is logged in can be challenging to track down and fix. When you are writing code you may optimize for those cases and have your code take different paths before it actually executes. While this is obvious if you are coding it’s not obvious when you are debugging as the permutations an execution can take are close to infinite in a large application.
When you are coding you can generally be pretty cautious of intermittent bugs which helps you avoid them, however in debugging you are at the mercy of the person that wrote the code. This is why intermittent bugs make debugging harder than coding.
In the graph above I tried to portray how unpredictable things can get when you are debugging an intermittent state application. My basis for this is basically that it can have a zig-zag or roller coaster pattern. You really never know when the bug will trigger which I think illustrates very well the difficulty over coding.
Lack Of Information/Context
Without proper context, it can be difficult to understand why a particular piece of code is behaving incorrectly. If you are debugging a function that is called from multiple places within the codebase, it can be difficult to determine which call is causing the problem without understanding the context in which the function is being called.
In the past I had to deal with this weird bug that I was debugging that was using environment variables. Unfortunately those environment variables were different based on each environment and it was hard for me to guess that they can influence the flow of the application. It turned out that in a specific context which I had no information about those variables had values that cause the application to crash.
I can tell you that it was one of the hardest problems to identify, now if I had coded that application it would have been a piece of cake to find the issue since I would know the code base. However this was an application I knew nothing about and was just debugging them on the behalf of a colleague of mine. As a result I finally found it but the lack of information and context made debugging harder than if I was coding it.
Concurrency And Multithreading
We spoke earlier briefly about race conditions over shared resources. Well now consider than you have a lot of different threads or processes in your application competing for a lot more stuff than just shared data.
The number of permutations your application can take and interaction or even synchronization between threads could lead to unpredictable behavior but also difficulty identifying the problem in a debugger. As you know generally debuggers require a context switching to go from one thread to another (or process). This alone adds a lot of tedious work but more importantly it adds a lot more difficulty as you now have to keep knowing the state of all those different lingering threads executing.
There’s a lot of ways to do this such as making mental or written notes but the fact that you have to undergo that process makes debugging concurrent applications hard. Granted coding concurrent applications is also very hard and I think it’s one of the most challenging things you may encounter in coding but debugging them takes the crown for the reasons we mentioned above.
Frustration
I think everyone has seen the memes of a developer pulling their hair when trying to find a problem in their code. If you have worked as a developer or done it as a hobby for more than 2 years for sure you would have experienced this in your life. Let me tell you some of reasons of why I’ve been frustrated from debugging code.
- You put all this time and effort and you want your code to just work as a mental relief
- You want to just deliver your application and get paid or rewarded depending on what you did it for.
- There’s deadlines and time constraints and this may stress you out to the point that you get frustrated.
- You are getting a lot of peer pressure and when you are not able to solve it you feel frustrated and embarassed.
- You profession may be at risk if the solution to your bug never comes, this is particularly frustrating if it happens in a certain environment and not in the one you are debugging it on.
I think the list above is pretty convincing of why Debugging is harder and more frustrating than coding but I don’t think you needed me to tell you this if you have been coding for sometime. If you are new the best way around it, is to go with some mental preparation and be ready for it because the debugging frustration will strike, trust me!
Future
One valid question is will that change anytime in the future. Without trying to be a prophet here there are some facts that we need to take into account and things will indeed change in the near future. However debugging will continue being harder than coding but lets see how things will change.
The most important thing to take into account is the introduction of AI and it being able to write code. There’s already widely available technologies right now that can write code. This will just become better and more prominent in the future. I can see major improvements in that area. However the same way there’s the possibility of automating code you can also automate debugging or even asking an AI to find bugs in your code.
I wanted to show you this trend graph from google trends to see the difference in popularity on ai coding vs debugging. As you can see there’s a clear correlation between the two in terms of when they spike but clearly coding and AI has taken off much more than debugging has. I believe this is mainly due to the reason that most people under estimate how important debugging is in the lifecycle of software development as a whole but none the less I think those two will eventually get closer to each other as one cannot exist without the other.
Before you tackle me let me tell you I know that finding a bug in source code is not the same as debugging as debugging is a general blanket that consists of more things such as environment, other processes running, third party libraries etc. The fact however that you can at least narrow out now of the hardest in my opinion aspects of it by using AI automation is crucial to keep in mind and understanding that debugging will be easier in the future, however not easier than coding.