Easy bug, difficult bug
At work, while working on a project a colleague showed me a UI bug: on a Win machine, there was a scrollbar visible that wasn’t meant to be there.
I knew the codebase, and it took me the time of the chat to fix the issue once pointed out.
Anyway, the experience of that UI bug triggered something in my mind.
I kept thinking about why we had this UI bug in the first place and how trivial was to fix.
I think I was so obsessed with the triviality of this bug because i did work on another codebase where you could spend days and days just to figure out where’s the issue.
So, here are my thoughts.
Easy bug
The bug was there in the first place because I work on Mac and Mac and Win machine handle scrollbars differently, even if it’s the same browser (in this case Chrome).
As said, I knew exactly where to place the fix within the code, and I knew the fix as it was not the first time I faced this type of bug.
In addition, I had already a Window VM setup.
Considering all the above, here is the recipe for an easy bug to fix:
- you have knowledge of the platform your software is running on (in my case win / chrome)
- you know how to reproduce the bug
- you know where in the codebase or libraries to place the fix
- you know exactly how to express the fix in code
Difficult bug
But what about the other codebase? The one you could spend days and days only to find out where the issue is?
It’s an old codebase, many developers passed by. No real documentation. Many libraries one on top of the others as a reminder of the fashion of the time passing by.
One nasty bug I remember was about one of these libraries — a UI library to be precise — having a dropdown not working on the latest Safari on the iPad.
Spent half a day only to update the operating system, setup xcode and the simulators to reproduce the bug.
Found that the latest version of the library was working fine but we couldn’t do the update because it was breaking existing code and fix it would have exploded the scope and timing of the task.
Found myself making a diff of the new and old versions of the library and discovered that the trick that was making the new version work was an updated regular expression used against the browser user agent.
The Safari user agent was changed somehow in the latest version of the iPad.
Chirurgically patch the regular expression in the old library and wrote plenty o comments to explain the situation.
Considering all the above, here is the recipe for a difficult bug to fix:
- you have no knowledge of the platform your software is running on (in my case safari iPad)
- you don’t know how to reproduce the bug or have very little clue
- you don’t know where in the codebase or libraries to place the fix
- you don’t know exactly how to express the fix in code
When you think about it, it’s quite simple. If you knew it all ahead, fixing a bug it’s just a matter of typing.
If you don’t know ahead, then you’ll need to investigate and learn. And that can be a quite challenging and time-consuming activity that will stretch you out of your comfort zone.
Last consideration: papers like Programming as Theory Building stress a lot on developers having knowledge about codebases, which is important but it’s only part of the story.
I would say that for a happy life with a codebase you need at least:
- knowledge of the platform your program is running on;
- knowledge of the codebase;
- knowledge of the programming language used; and
- knowledge of how to express solution with it.
For a frontend codebase, knowledge of the platform your program is running on means knowing the browsers. All of them. Across operating systems.
While for the last point, knowledge of how to express solution with the programming language used consider this: you may know the programming language you use on your codebase, but sometimes, for some types of issue, you may need to know some not obvious way to use it to provide a viable solution.
E.g.: the fact that you know how to write a function doesn’t mean you know how to use a callback or when to use a callback or if a callback is the right solution for a problem.
Conclusion
In summary, we saw how the knowledge of the platform, the codebase, the programming language used and how to express solutions with it have effects on fixing bugs and producing quality code.
Without that knowledge, investigation and learning will be required, which after all are the heavy tasks when programming.