Groan: Victims of Data Breach Receive Letters Intended for Others

I’ve blogged about this data breach before: Federal Department Bans Use of Portable Devices (YAFF).  To add insult to the injury, a “printer error” has led to recipients of notifications about the breach receiving letters intended for other victims.

The federal government is blaming a printing error for the fact that some student loan recipients who received letters to say their personal information had gone missing along with a portable hard drive also got letters addressed to someone else.

Human Resources and Skills Development Canada revealed last month that a hard drive containing the personal information of some 583,000 Canadians had gone missing. The data included social insurance numbers and dates of birth of people who had received student loans between 2002 and 2006.

via Victims of student loan data breach get letters addressed to others | CTV News.

Sure, these sorts of errors do happen, especially when using automated printing and envelope stuffing equipment. I’ve got to say, though, that the timing on this error is more than … difficult.  I’m wondering if the IT teams are being blamed here, or just the outsourcing company that provides mailing services.

214-748-3647, Hello…Is it Me You’re Looking For?

A developer, Justin Reese, just shared his own story about using the wrong datatype for phone numbers, over at DailyWTF.  He did this in an XML document, but I see the same mistake being made over and over again in data models and database designs.  In fact, this is a key part of my Data Modeling / Database Design Blunders presentation.  

My client reported that was a strange bug on a certain page in an app I built for them. Where the contact information for a series of offices was being displayed, all the information was correct except for one piece: the phone number. For multiple locations, the phone number displayed was the same: 214-748-3647.

I love reading about his quest to track this problem down and what the issue turned out to be.  I also love that he wrote a DailyWTF about himself.  We all should be doing that: sharing our mistakes so that others can learn from them.  I call that "Free Advice That’s Paid For" in my blog posts. 

In my presentation my first blunder is using numeric datatypes for data values that aren’t actually numbers.  Telephone numbers are one of them.  They may have leading zeros.  We don’t do math on them, usually.  ZIPCodes are another example. Store them as INTEGER and you’ll lose leading zeros.  And many Postal Codes have letters.  Think you have only US customers? You might.  But customers, people who may owe you money, have a way of moving around.  Of course, every design decision comes down to cost, benefit and risk.  So some designs may make a good case for using numeric datatypes for storing values that aren’t actually numbers. But all the protections for data quality and correct retrieval need to be designed in, too.  That’s the trade-off.  Also in my presentation I give a rule of thumb:

If business users call it a number, it ain’t a number. 

Customer Number. Account Number.  Vehicle Identification Number.  Social Insurance Number.  Social Security Number (yeah, it’s all numbers now, but nothing would stop the powers that be from changing that).  This is especially true for numbers that are managed by people outside your organization.  You just don’t know when they might decide to add letter or special characters.

I get feedback from at least one person at each presentation that my blunders are way too obvious or that they aren’t serious mistakes.  As much as I see poor or inaccurate datatype selection, I have to politely disagree.  These are the number one mistakes I see.  They compromise data quality, lead to tragic data errors, even.  Storing numbers that in fact aren’t numbers as INTEGERS or other numeric datatypes is error prone, leads to nasty slow queries due to all the casting and table scans that may happen.  Eventually, those incorrect data values are going to come looking for you.  Usually after work hours, in production. If you’ve never seen them in the wild, then either you don’t get out enough of you’ve been blessed by working with highly competent data modelers and database designers.  And we all know how rare those are.

Thanks to David Maxwell (@dmmaxwell | blog) for the pointer to this WTF

First Day of Work Karen: What I Would Tell Her #mememonday

It’s time for another Meme Monday, as assigned by Tom LaRock (blog |@sqlrockstar ). In his post, he asks us to write about:

If you could go back in time and meet yourself on Day One of your IT career, what advice would you give?

What a great question.  I’ve previously blogged about What I Would Tell my 16 Year-old Self .  All good stuff there.  Especially about the hot rollers.

But what would I say to Karen Lopez, brand new Senior Systems Analyst (yes, that was my first job title)?  There a bunch of small stuff that really turns out to be big stuff later:

• Skip the Full Day Voice Mail Training.  Sure, it was mandatory, but the guys only had to do a half-day version of it.  Insist you don’t know need a full day.  Set the direction for how the team sees your role on the project from the start.
• Don’t let that clerk at the Passport Office talk you into bad data quality: alphabetizing your names on your passport.  That one decision is going to impact you more than you can ever imagine.  But you will get some great data quality presentation material out of it.
• Respect your boss, but don’t let him manage your career.  My first boss started on the same day I did.  He wasn’t a twenty-something, though.  He had retired from the US Army the day before and had come to work for the defense consulting company I worked at.  To manage projects for the US Army.  Funny how that works.  He brought with him his military bearing…and his need to be in command of everything, even the technical design of the application we were building.  Even though he was an accountant and had no technical experience or training. 

  He and I didn’t really look at life the same way, but he was my boss.  I let him manage my professional development plan, my training, my assignments much more than I should have.  He wasn’t a good fan of female engineers, either.  So our non-technical tester was the guy who did all the demos and presentations, even though he really could answer any of the technical questions he received.

  Karen, that boss should not have been able to set your path, only guide it.

• Don’t try to explain everything that caused a bug or a mistake in a deliverable.  Just fix it and fix the problem that led to it.  Nobody really cares why it happened unless the think you are going to do it again.  Fix it, learn from it, move on.   Don’t make your mistakes stand out more than anyone else does.  Be honest, but don’t broadcast them.
• Never accept the first offer.  I can’t tell you, Karen, how many times you are in a negotiation and don’t even realize it.  The earlier you realize this, the better off you will be.  Think your boss is doing you a big favor by sending you on a local one day course?  Sure, she is.  But she’s sending Chad on a full week of bootcamp training because he asked for that instead.  Think you are fortunate because you are getting a 5% raise? You are, but Chad got 10% because he negotiated it.
• You will make great friends at work.  But they are your colleagues first.   Save the details of your life for friends outside work.
• No one cares what shoes you are wearing…as long as you can keep up the sprint with everyone else.  Wearing impractical shoes is going to slow you down. That’s literal and figurative advice.  See, double the value.

I think First Day of Work Karen did okay over the years. She got to work at all three branches of the US government during her first job.  She played volleyball on the Mall.  And she learned a lot about voice mail, a bleeding edge technology then.  But there were more important things to learn along the way.

Sometimes You Just Shouldn’t Jump In Feet First #FailFriday

Pipeline im Bau (Photo credit: Wikipedia)

 

Thinking about it, this could also be titled “There’s No I in Team” or “Communication is Key”.

About 20 years ago I was a young(er) Engineer working away at a company learning all about how things worked.  I was given the task to look after and inspect a pipeline project that was about 20 kilometers long.  One of the tasks at the end of the project is to test the pipeline before it is put into service.  The tests are done with water and the pipeline is pressurized almost to its full theoretical yield strength.

In the days leading up to the tests there wasn’t much for the inspector (me) to do so I helped out the contractor doing some menial tasks on the site.  One of them was filling this long pipeline with water.  We used a small water pump that pumped at a maximum of about 200 psig.  Not much compared to the full yield pressure we were going to test at.  As you can imagine when you are testing a pipeline at over 1,000 psig you have to use some pretty heavy duty fittings so we could pretty much do whatever we wanted with that little pump…including closing the valves with the pump running.  Remember this as you read on…

The day of the test everyone got there, we set up the test assembly, the dead weights to measure the pressure and a high pressure piston pump.  This piston pump can pump in excess of 3,000 psi, but it pumps relatively slowly compared to the pumps we used to fill the pipeline.  But think about it, water is incompressible so if the pipe is already full of water it doesn’t take a lot more to get it to the test pressure.  I forget the exact values, but it was probably about 400 to 500 gallons of water that we needed to pump in.

So we started pumping water and found it was taking extra time to get the pressure to rise the way it should.  Sometimes you see this if there’s a bit of air in the line, but in this case the pump just seemed extra slow.  I had been on tests before (and had them go wrong before) and I knew (or thought I did) what was happening.  We stood at the top of the excavation looking down at the test head and wondered what was wrong.  Without saying anything to anyone, I jumped in the excavation and put my ear next to the valve.  It didn’t sound right to me.  So guess what I did….I closed the valve.  In my mind I thought there might be something in the valve and if I closed it and opened it again right away maybe it would help.  It was a sound theory, right?  Wrong.

Remember what I said about using heavy duty fittings?  The valves were 2” ball valves rated at 3000 WOG or 3,000 psig.  Remember what I said about the piston pump being able to pump in excess of 3,000 psig?  Guess what happened when I closed that valve WITH THE PUMP RUNNING?  Let’s just say I never got the valve open again.  I took the top of the valve, the handle and the stem in the chest.  Lucky for me I was bent over the valve far enough and it was late fall I was wearing enough winter gear it wasn’t too bad.  I got a face full of water right away so I didn’t even realize I got hit by anything else.  It wasn’t until later that I started feeling a dull ache that let me know.

I was working with a team.  Had we actually talked about the issues and what we should be doing I never would have dead headed such a strong pump against a closed valve.  We may have closed the valve and reopened it based on my theory, but we would have shut the pump off first.

Sometimes you just shouldn’t jump in feet first.

Yeah, Those Strawberries #FailFriday

As I called for last week, this is my #failfriday blog post.  I’ve made so many mistakes, it was difficult to pick one.  There was the time I did a quick spellcheck of a letter to a key client and managed to change his name to Murderer, as in Dear Murderer.  Those were good times.  Then there was the time I generated and printed about 1000 graphs for evidence in a court case and managed to screw up the last data point on every single one of them.  This was an instance of an off-by-one error.  So they all had to be redone on a pen plotter.  That takes days….and lots of pens.

Of course, I’ve had many of the #fails that most people shared on Twitter: Running a script or command in the wrong location, usually the wrong server or directory, and wiping out data that had not been backed up.  I have a feeling this is a requirement to become a professional: this fail changes you for the rest of your career.

I decided to pick a trivial fail, but one that showed the dangers of being a data architect.

Strawberry Fields Forever

In Ottawa I lived near a strawberry farm.  How wonderful it was to have fresh strawberries, picked minutes before, for several weeks.  One night I was driving back from the city and stopped by the farm to see if they had any for sale.  I remember I was wearing a suit, heels, the whole business chick outfit. Not really strawberry picking attire.  So I was on a mission to get berries that had been picked by other people.  You could buy strawberries two different ways:

• Pick Your Own:  Basically the farm gave you trays and you picked your own and paid the cheapest rate.  Because carrying trays was hard work, people would fill the trays, then bring them to sales hut to hold them.  Then the pickers paid for all of  them at once.
• Already Picked: Local kids would pick the berries and bring them to the sales hut and get paid for picking them.  Buyers like me paid a premium for having the hard part done for us already.  However, if you got there late in the day, like I did, the chance of finding these was rare.

So this was my plan: buy a flat of “already picked” berries.  That was my category, remember.  Not “Pick Your Own” but “Already Picked”.  See, I was thinking like a data architect.  Those were 2 subtypes of STRAWBERRY: ALREADY PICKED STRAWBERRY and PICK YOUR OWN STRAWBERRY.

So I waltzed up in my blue power suit, looked at the shelves in the sales hut and saw many flats of berries and asked the bored teenage sales girl “Are those strawberries already picked?”

Are those strawberries already picked?

….I’ll let you guess what happened next.  If you picked “laughter, eye rolling and general snickering”, you’d be spot on.  See, it turns out that the sales girl didn’t live in a land of data architecture, where everything is categorized, sorted and taxonomized to the 9th degree.  She lived in the real world, that place where strawberries are either still on a plant or not. 

I  learned my lesson that day.  Data architects sound funny outside their normal habitat, those whiteboard-shrouded conference rooms where data is managed.  And sometimes we sound really silly in the real world.  We need to remember that.

#FailFriday meme: I Was Young and Didn’t Know Any Better

For 24 Hours of PASS I moderated a panel of SQL Server experts on mistakes they made: I Was Young and I Didn’t Know Any Better.

So I’m inviting everyone, including my panelists, to share a mistake they made, how they recovered from it, and the tips they want to share on making things right after making a mistake.

While this is a #FailFriday meme, you can take your time to put your post together – post it anytime in the next week.  I will summarize all the posts here.

For this week, you should write about mistakes you made because you were inexperienced.  We’ll have a new #FailFriday about other type of fails next month.

No need to do anything special for linking.  If you want to appear in the summary, use the hashtag #FAILFriday or leave your link in the comments.  My post coming up when I get to the next airport.