This chapter is from the book
This chapter is from the book
This chapter is from the book
12.4 Conclusion
There’s a significant degree of personal experience involved in troubleshooting. I once worked in a team where a unit test failed on one developer’s machine, while it passed on another programmer’s laptop. The exact same test, the same code, the same Git commit.
We could have just shrugged and found a workaround, but we all knew that making the symptom go away without understanding the root cause tends to be a myopic strategy. The two developers worked together for maybe half an hour to reduce the problem to a minimal working example. Essentially, it boiled down to string comparison.
On the machine where the test failed, a comparison of strings would consider "aa" less than "bb",and "bb" less than "cc". That seems fine, doesn’t it?
On the machine where the test succeeded,however, "bb" was still less than "cc" ,but "aa" was greater than "bb". What’s going on?
At this point, I got involved, took one look at the repro and asked both developers what their ‘default culture’ was. In .NET, the ‘default culture’ is an Ambient Context [25] that knows about culture-specific formatting rules, sort order, and so on.
As I expected, the machine that considered "aa" greater than "bb" was running with the Danish default culture, whereas the other machine used US English. The Danish alphabet has three extra letters (Æ, Ø, and Å) after Z, but the Å used to be spelled Aa in the old days, and since that spelling still exists in proper nouns, the aa combination is considered to be equivalent to å. Å being the last letter in the alphabet is considered greater than B.
It took me less than a minute to figure out what the problem was, because I’d run into enough problems with Danish sort orders earlier in my career. That’s still the shifting sands of individual experience—the art of software engineering.
I’d never been able to identify the problem if my colleagues hadn’t first used a methodology like bisection to reduce the problem to a simple symptom. Being able to produce a minimal working example is a superpower in software troubleshooting.
Notice what I haven’t discussed in this chapter: debugging.
Too many people rely exclusively on debugging for troubleshooting. While I do occasionally use the debugger, I find the combination of the scientific method, automated testing, and bisection more efficient. Learn and use these more universal practices, because you can’t use debugging tools in your production environment.