Things are the way they are...
During TestBash, I was particularly drawn to Joep Schuurkes' presentation about introducing new testers into an established testing team. He mentioned a particular Jerry Weinberg quote which has been reverberating in my head ever since:
Things are the way they are because they got that way ... one logical step at a time.
Weinberg, The Secrets Of Consulting (1985)
I've been hearing echoes of this sentiment in some weirdly obtuse scenarios that I've been testing this week; situations which made me think "How did that ever come about?"
Backslash character rendered as ¥ (Yen) in Japanese / ₩ (Won) in Korean
I was testing a change in our application's file-system layer, which occasionally has the need to concatenate a folder location to a filename, with the ability to handle whether the folder location ends in a terminating backslash.
When reviewing the code, I noticed that there was a mixture of
Path.DirectorySeparatorChar and the literal
"\" character in the code. I was concerned whether this inconsistent usage would cause problems on non-English operating systems; for instance, in a Japanese environment, where I'd previously noticed that Explorer uses the Yen currency separator instead of a backslash:
As it turned out, I didn't need to be concerned with any runtime problems. Where our code was referencing backslashes, the Japanese operating system was still interpreting this as a directory separator character.
Which still made me want to know... why? It's still not clear how it happened, although the issue was once acknowledged in the following Microsoft developer blog post: When is a backslash not a backslash? (from Archive.is; original post no longer available)
After acknowledging the issue, the author cites one of his colleagues, who displayed sentiments which echoed Weinberg's famous words:
When one of my customers from Korea was visiting here, I asked him if it bothered him that the backslash doesn’t appear as a backslash. It did bother him, and he believes it bothers most of his countrymen. However, he was fatalistic about it: "What can we do to change it. It’s been this way for a long time. We are used to it."
"Fixing" this behaviour at an O/S level is likely out of the question, as the behaviour needs to be maintained for the sake of backwards-compatibility. But once I'd noticed this quirk, I started noticing it in other places too - in Word 2010's advanced layout options, for example:
Stumbling upon little things like this is one of my favourite parts of my job. It means that my future investigations in this area can be augmented with the knowledge of a thousand frustrated people before me. Speaking of which...
Command-line allows numbers to be mapped as drive letters
This one's a little more straightforward, if equally puzzling. When mapping/mounting drives in Windows, the drive has to be assigned to a letter (for instance, the E: drive). Our application has some code for checking whether a folder path is fully-declared, and whether it is a local or network/UNC path.
The code for checking "Is this a local path?" began by checking whether the path began with a letter, followed by a colon. Like before, I couldn't say for sure whether this was a safe assertion; but I had concerns that maybe it wasn't. A quick search brought me to the Drive Letter Assignment topic on Wikipedia, which offered up this interesting snippet of information:
...it is possible to mount non-letter drives, such as 1:, 2:, or !: using the command line SUBST utility in Windows XP or Vista (i.e.
SUBST 1: C:\TEMP), but this is not officially supported and may break programs that assume that all drive letters are "A-Z".
"May break programs"? That sounds like something that I'd quite like to test for! What an unexpected find! My curiosity had rewarded me.
The same wiki topic also provided some history/background into the drive letter support of various systems, stretching back to the likes of DOS and GEMDOS, and so once again it's likely that this quirk exists now solely for backwards-compatibility purposes.
As it turned out, we didn't actually have any problem to fix here, and I suspect the "not officially supported" line may have given our developers a get-out clause anyway; but I love that I'm in a position where I can learn about oddities like this, as it may prove useful in future development discussion.
These two pieces of unexpected behaviour are a reminder to us that (as per Jerry Weinberg's quote) a series of decisions, made in the heat of a series of moments, can lead us down a potentially undesirable path. It's one of the reasons why teams end up with things called "legacy tests", and weird bits of inexplicable functionality in our applications; "It all seemed like such a good idea at the time..."
How can we avoid this sort of thing? Planning would seem to be key, specifically giving thought to long-term architectural decisions, rather than just implementing a change which is "good enough". Planning isn't a dirty word in agile; making good use of epic user stories can help, as can backlog grooming, aiding the team to gain an awareness of longer-term plans which can affect the decisions that we make today.
But until the miraculous day when every decision is made with every possible outcome in mind, there'll always be a place for testers (and developers) who question assumptions and ask "Do we really know why it behaves that way?"