Oh, the places you'll go

One of the things that took the most effort building the eBay checkout interface for PayPal was making sure everything appeared correctly no matter in which area you lived. To show how different this is, let's look at a few differences between my two favorite countries - the United States and Ireland.

Let's look at three simple, obvious examples first...like an address

The Lord Mayor of Dublin	The President of the United States
Mansion House Dawson Street Dublin 2 D02 AF30 Ireland	The White House 1600 Pennsylvania Ave NW Washington, DC 20500 United States

If we think of this as a microformat, both have a street-address - Dawson Street or 1600 Pennsylvania Ave NW - and both have a locality (city) - Dublin or Washington - and both have a country...and they even (now) both have a postal-code. The number after the city name in the Lord Mayor's residence works something like a postal code, but it's not - and it's also not the locality, it's a region within the city. Additionally, the Ireland address also has no region...and as with many street addresses in Ireland, there is no building number. Nearly every country has its own addressing scheme - and yes, there are addresses written in a format similar to the US format - but there are often differences and they seldom end with the physical address.

Telephone numbers are displayed differently. For example, the Lord Mayor's telephone number is currently shown on the website as 01 222 6200 (which leaves off the country code, though to be fair I'm sure it's seldom that anyone calling the Lord Mayor from outside Ireland would not know to dial 353 beforehand) and on the website for The White House the switchboard is listed as 202-456-1414 (again leaving off the country code). The minor difference here is that in the US there is nearly always a clear delineation between the parts of a telephone number - e.g., the area code is first and is typically either followed by a hyphen or a space and sometimes it is wrapped in parentheses and sometimes it's missing altogether. The central office portion (that's the 456 bit in the number for The White House) is followed by a hyphen but sometimes a dot - I don't recall the last time I saw it connected directly to the line (e.g., 4561414) or the last time I saw it followed by a space.

Finally, let's look at dates. I don't mean those tasty bits of chewy goodness that grow on tall skinny trees, I mean days of the year. In the US you'll nearly always see them collected and displayed as month followed by a slash, then date followed by a slash, then year - for example, 12/31/1999 for New Year's Eve in 1999. The US is nearly the only country where you'll see this month-day-year format. In most other countries, including Ireland, you're much more likely to see day-month-year (which you'll also see if you're looking at a US government document, but in that case you're likely to see that same date as 31-DEC-99).

Why does all this matter?

First there are the little miscommunications - like when the British Prime Minister was scheduled to visit The White House and several individuals were not admitted because the dates they provided as birth dates didn't match the date security personnel had.

Second, there are bigger issues - for example goods and money can be misrouted, negatively affecting any number of things such as someone's life or livelihood.

For people focused, in even a minor way, on developing software people have to actually use, there are two points of impact. First, having to adjust for myriad tiny differences increases the cognitive load - which is a significant contributor to conversion. Second, the amount of time spent localizing an application can be significant, because not only do interaction points - like date collection inputs - have to be localized, designs have to accommodate longer words without breaking.

My experience in working with both Fortune 500 corporations and small consulting firms has shown me one consistent truth - US firms focus on developing for the US market first. Granted, the US is a big market, but imagine if you were an auto manufacturer and you learned that every car you produced had to be customized for the customer. It's not that every customer wants a different color, it's that one customer wants four doors, another two, the next wants five, and yet another wants one and he wants it to open vertically behind the motor so he can climb over the steering column. You'd likely say that's nuts - we'll build a car with four doors and everyone will use the same car. There's a legend that Henry Ford said something like that - you could have any color Ford motorcar as long as it's black - and he did get away with it, for a time. In these days of being globally aware, your organization is not likely to have the same option. If you want to sell widgets in China or Mexico or Germany, you'll have to appeal to the Chinese, Mexican, or German market - or at least not make them hate buying your widgets until they can find a new source.

If you are going to launch in a global market - any global market - build your software from the perspective that you will be internationalizing it. Build a common interface, but build it in such a way that it reduces cognitive load and has the best experience for the greatest number of people. In the long run, you'll be glad you did...and when the next customer wants zero doors and handlebars in place of a steering wheel, you'll be able to say "here's your motorcylce" in weeks rather than months.

Happy coding.

Don't play Jenga® with the code (Robert's Rule #20)

[Tweeted 2011-06-17]

Often code is developed in concert between many developers. In times like this we all hope that the code is well-documented and is written in a style that is easily readable. Unfortunately, this is not always the case, but even when it is the case there is still a danger because seldom is production code so clean or simple that every developer understands all aspects of it. A good example of this is code for web applications, especially front-end code in JavaScript.

JavaScript is deceptive for a number of reasons. First, it's similar enough to Java that engineers who work in both languages will sometimes get confused. Second, it's strengths (or weaknesses, depending on your perspective) allow poor writing. Third, while it's possible to simulate multi-threaded programming, there isn't anything that's considered thread-safe. This last point has, in my experience, been the most challenging because it has the potential to create race conditions...on steroids.

Because of its deceptive nature, to say that debugging front-end web code can be a challenge is a bit of an understatement. One approach, often used with linear programming, is to comment out code while stepping through it to see where the defect lies. Unfortunately, this plays right into the language's deception by creating the equivalent of a red herring, and with it the potential for disaster.

In those cases, it is always best to not only keep exact notes, including a time stamp, when attempting to reproduce the defect. After completing several tests, search the code to find the handlers for the actions taken while simultaneously examining the logic within the event flows. Finally, make sure that at least one person on your team is intimately familiar with each codebase so they can act as a resource. It is only by pursuing a course of action similar to this that you follow Robert's Rule #20, don't play Jenga^® with the code by pulling out pieces that you believe to be the problem only to have the application crash to the ground.

Past performance does not guarantee future value (Robert's Rule #4)

[Tweeted 2011-04-28]

A while ago I was in a job managing a team of software engineers. This team was a mix of people; both in terms of experience and in terms of relationship to the company (i.e. some were full-time employees and some were contractors).

Now, I tend to consider myself more detail-oriented and data driven than the average person, so it made perfect sense to me to relate software features to be developed, and all the project management related data (estimates, dependencies, etc) to my assessment of a developer's skill level and also relate the defects found to the features. In hindsight it was, perhaps, a tad more complicated than it should have been. On the positive side, it gave me quick insight into how effective my assessments were and how likely we (as a team) were to hit our projected development milestones.

One of the problems I faced was when developers took up a different task or a different language. Software development, as a discipline, is fairly straightforward. There are language skills (computer languages are made up of nouns and verbs and have direct and indirect objects just like other languages) and general concepts (like data normalization rules and network/communication protocols) that apply to all feature development, so a good developer is a good developer, right? Usually.

Usually good developers get better, but practice doesn't make perfect and a developer that handles one language with ease may not be able to make the switch to another language. Such was the case when one of the developers on my team attempted the switch from COBOL to an object-oriented language. When he popped the clutch on his paradigm shift (yeah, I started that saying back in '93) his development shuddered like an old car. In a car, if you pop the clutch, you can stomp on the accelerator and rocket off or you could try to coax it along and kill it...I believe that in theory it works the same with people.

This experience led me to conclude that "past performance does not guarantee future value" is just as true for people as for the stock market (Robert's Rule #4). This developer chose to try to coax his development along rather than immersing himself in the new technology. I don't know where his career has taken him in the years since, but it's most likely out of software engineering.