Home » True Stories » Doing Things Right vs. Doing the Right Thing

Doing Things Right vs. Doing the Right Thing

Start here


Cultural awareness.

I recently worked on a project that was off-shored. For the most part things ran pretty smoothly but there were a number of issues that were insanely simple (from my perspective) yet became overly complex over time.  The primary cause, I believe, was cultural differences between testers here in the U.S. and the off-shore development group.  Three simple things that took weeks to resolve:  currency formats, sorting of dates, and phone number formats.  I know what you’re thinking.  How complicated can it be.  Trust me, I lost a lot of hair over these three seemingly simple concepts.
The first one had to do with formatting U.S. currency values – specifically negative values.  The application dealt with currency values on a number of pages.  The customer was a U.S. state, so nothing other than U.S. currency values was involved.  There were a couple of different formats depending on the page you were looking at.  Pages displayed one of two different formats for negative currency values: -$1234.56 and $-1234.56.  Which is correct?  Common usage will tell you the first one is correct.  Unfortunately, there was no specific requirement on formatting currency.  So instead we looked to Microsoft Excel for the answer.  The answer was example 1: -$1234.56 (actually the default was (1234.56) but that’s another story).  We asked them to change it – they did with no argument.
Second – date sorting.  Again not specified in the requirements because according to the Business Analyst: “Everyone knows this.”  Apparently not.  So if we wanted to sort table data by date we have two options:  ascending and descending.  That’s where the problems started.  We had different definitions of what those words meant.  With alpha characters or numbers – not an issue.  With dates, not so much.  The requirement stated only that records would be displayed, by default, in descending order, by date.  To me, that meant the most recent record first through the oldest record.  When the application was delivered to test we got the opposite – oldest records first, newest records last.  So I wrote it up.  In the bug triage meeting there was a huge argument over the concept of ascending vs. descending.  To our off-shore partners descending order by date meant oldest records first, newest records last.  They had a pretty good argument.  Again, Bill Gates to the rescue.  “What would Microsoft do?”  We finally agreed that descending order by date meant most recent records first and oldest records last.  It only took an entire afternoon to resolve it.  Once again we asked for a specific requirement.  We were denied because requirements shouldn’t address “common sense” issues.  Whatever.
The third issue – phone number formatting – was not so easy.  This time we had a requirement.  Vague – but a requirement none the less.  The requirement basically stated that system would display 10 digit phone numbers using a dash and pair of parentheses.  Well that is exactly what we got.  A phone number was displayed as (5)55-5555555.  Does it meet the requirement?  Absolutely!  Was it a valid U.S. phone number?  Not a chance.  So I wrote it up.  The off shore contractor fought this one for almost a week.  They swore that this was correct and in accordance with the requirements.  They refused to change it.  We found out later that they were penalized if the defect count got too high.  So we figured we would reword the requirement to be more specific.  Easy fix right?  Wrong?  The Business Analysts fought changing it again citing the “common sense” doctrine. A week later, after a lot of arguing, the requirement was changed and the format fixed.
In looking back, I feel that this whole mess came down to a difference in culture.  First of all, the off-shore vendor was a third world country and had no clue how this type of application should work, look, etc.  Also, their culture does not condone “mistakes.”  Defects made them “lose face” so they fought each and every defect we found.  (The defect penalty in the contract didn’t help).  Lastly, this was a culture that prides itself on “doing things right.”  What is right?  In this case the requirements defined right and wrong.  It was either black or white.  “Doing the right thing,” on the other hand is a gray area.  Harder to define.  You know it when you see it.  It’s sometimes hard to define.

The lesson learned:  when dealing with other cultures, common sense may not be so common.



  1. “In looking back, I feel that this whole mess came down to a difference in culture. ”

    Perhaps. But it seems there’s also a difference in expectations.

    They were expecting to follow the written Requirements precisely. That implies the need for full, comprehensive, less-ambiguous Requirements.

    You were expecting that this sort of Requirements wasn’t needed – that they would understand what you wanted even if it wasn’t completely specified in writing, or that you could guide them over time to understand what was wanted.

    This can happen any time that expectations aren’t coordinated up front. It can happen with offshoring, local outsourcing or insourcing.

  2. SheyMouse says:

    There can even be these kind of misunderstandings within a company! How prescriptive is too prescriptive in a spec?

  3. Cap'n Dave says:

    Thanks Joe and Shey!

    Good points. How much is too much? How common is common sense? Depends on the audience I suppose.

    You rarely go wrong with too much information. I say the more detail the better, especially if it is an off-shore project.

    Lesson learned on my part.

  4. shilpa says:

    We faced similar issues when we hired an offshore company. But it also helped stream line our existing processes because we took some things for granted. We called this the “we always did this way” loop which had to be broken when we involved outside groups. I think this is a change in the right direction.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: