The last week I spent two or three hours
looking for the cause of a bug really close to the place where it was actually
located – but not close enough. From the exact moment when I opened the bug
description in Visual Studio everything pointed me in the right direction –
towards a couple lines in our code base, fixing which would have resolved the
issue. However, when reproducing it according to the steps outlined in
the issue tracker and exploring the related behavior of the system I have caught
a glimpse of something peculiar, that could have been the reason of my issue, and it made
me waste a lot of time on trying to fix the wrong problem.
A particularly important detail about this new problem that I discovered was that its incorrectness didn’t look like something trivial and minor. It
seemed to me that I was looking at a very severe bug spanning a number of components of our system. At some point, I
was almost sure that I have found a really big problem, much broader than what
the reporter could have thought. This feeling of stumbling upon something significant that might have far-fetching consequences quickly made me
forget my initial objective.
Moreover, I was excited in a very negative way
by the idea that I see something that other devs on the team have overlooked,
and the desire to show everyone how cool I am pushed me even further away from
what I should have been fixing. The fact that the newly found problem looked
much more complex than what followed from the original description also meant that it was more interesting. Hence, my
eagerness to fight it instead of taking a broader look and examining all the
aspects of the problematic process.
It took me a couple hours of digging and a relatively long break to persuade myself that I should try and go through all the steps that
cause data corruption and the related error. Initially, I have stopped my attempts to
find the exact source of the issue once I had spotted something strange and
unexpected. Should I just follow the description of the issue, carefully
crafted by the QA engineer, up to the point where the problem is clearly seen, I would have reached the root
of the problem much faster – maybe in a matter of minutes.
What happened instead is actually very familiar to me –
that’s not the first time I make this mistake. From time to time, when tracing
down a bug I face something strange-looking in the middle of the way and start exploring it. I do this despite being fully aware of the idea that any problem must be solved from where it manifests itself down to its
actual reason – without taking any shortcuts. I know that one should under no
circumstances skip any steps on this way, but I still do this occasionally and
it never brings me close to where I would be happy to find myself.
This exact problem is what the strategy of
moving slowly and in tiny steps aims to solve. For me the nature of the issue
began getting clearer once I pushed aside the keyboard and started writing – with
pen and paper. These tools make one work slower, they don’t allow to hack one’s
way through the code and skip crucial points. Moreover, they facilitate deeper
and calmer thinking, while rapidly stepping over the lines of code in a debugger or
executing numerous variations of an SQL query usually
descends one into a state where only wild guesses and ‘let-us-try-this’ hacks are
possible.
My takeaway is once again that one must not
rush to solve any problem that they happen to see – frequently what we initially perceive as incorrect behavior turns out to be desired in the end. Instead, one should work towards fixing what they aimed at first. In many cases problem solving works better if one maintains a queue of
the problems – not a stack. Fortunately, even though our minds seem to be using
a stack internally, we can always push extra problems out of it – to a bug-tracker
or to a good old sheet of paper – so that the original, the right problem can
be fully comprehended and solved, giving way to new glorious fixes.
Комментариев нет:
Отправить комментарий