Browsing articles tagged with " Data Model"

Lose Data Model Errors with This One Weird Trick

Apr 30, 2015   //   by Karen Lopez   //   Blog  //  No Comments


What could that datatype possible mean?

Read my blog post on an ER/Studio secret over on Embarcadero’s Community site and find out.

Refactoring Computer Engineer Barbie

Jan 30, 2014   //   by Karen Lopez   //   Awesome, Blog, Data, Need Your Help, Snark, WIT, WTF  //  23 Comments

imageIn mid-January I came across a link to a story about a new book by Random House called Barbie I Can Be…A Computer Engineer.  As you know, I travel with a Computer Engineer Barbie (@data_model) and Venus Barbie (@venusbarbie) in my work advocating that girls take more STEM courses.  So let’s say I have a strong interest in making sure my wonder girl Barbie has a great book.

But the story said that the book actually put Barbie in not so great place.  So I bought the book and read it.  And it made me cringe.  I read it a few times and decided it needed to be fixed.  Or in Computer Engineering terms, it need to be refactored.

So that’s what I’ve done.  In this review of Barbie I Can Be…A Computer Engineer, I will point out the parts that set a lousy role model for girls and offer suggestions on how it can be refactored to make it better.  Just like in software refactoring, I’m not going to change the functionality of the book, but I’m going to improve the code words to leave it better.

And to make it easy for you to fix you copy, I’ve included a Refactoring Computer Engineer Barbie PDF. You are welcome.


Barbie is working on a design for a new puppy computer game when her laptop catches a virus.  Luckily, she wears a heart USB drive around her neck and has backups of her files.  So she uses her little sister’s (Skipper) laptop to try to retrieve the files.  Oh, CURSORS! she has infected Skipper’s laptop, too.  She promises to make it all right and rushes off to school to ask her computer teacher (who is a female!) how to fix it. Her teacher gives her some tips and Barbie heads to the library to get get both her data and Skipper’s data back.  She gets two friends to help and they get it done.  Skipper, with her restored data, makes an excellent presentation in her class where she says that Barbie is the person she most admires. Cue tears.  Barbie presents her game in computer class.  She does such a wonderful job, her teacher even gives her extra credit.

The End.

Well that sounds Awesome! Isn’t it?

Sounds like a great story with good female leadership, doesn’t it?  Female teacher, Barbie and friends fix the problem, Skipper and Barbie give great presentations.  We need more great females to speak, right? Well, just like in database design, the Devil is in the details.

Unfortunately, some of the details really make it look like Barbie is more of a Booth Babe than a Computer Engineer.  This is making the IT community cringe. Twitter is blowing up with campaigns to get the book removed from shelves or to get Random House to fix it.  Well, I’m going to save Random-House the effort by fixing refactoring it for them.  It’s one thing to raise the issue, but as a designer-architect-project manager-methodologist-computer engineer, I just want to FIX it.

Let’s start with the first troublesome passage:

Computer Engineer Barbie Laughs and is Needy


"I’m designing a game that shows kids how computers work", explains Barbie. "You can make a robot puppy do cute tricks by matching up a color blocks!"

"Your robot puppy is so sweet," says Skipper. "Can I play your game?"

"I’m only creating the design ideas," Barbie says, laughing. "I’ll need Steven’s and Brian’s help to turn it into a real game."

That last line is a problem. First, saying “I’m only” makes it look like design work is some how lesser than building.  I know there are some techs out there that would agree with that, but it’s still not true.  In fact, in technical professions, the designer / architect is the senior position on the project.  Secondly, she is laughing this line, as if it is hilarious to think that Barbie can build something.  Finally, Steven and Brian are recurring characters throughout the I Can Be… book series.  They are friends and friends help each other.  But this passage seems to reinforce a position that boys build, girls draw.

So I’ve refactored this passage by changing out that line with this one:

"Not yet," explains Barbie. "I need to finish the design then work with Steven and Brian to turn it into a game."

See how that says basically the same thing, but it doesn’t devalue Barbie’s design work? It also reinforces the more realistic situation that teams work together to make a product.  Barbie doesn’t “need help”; she is part of a team to get it done.

Steve and Brian Will Get It Done Faster


After class Barbie meets with Steven and Brian in the library.

"Hi guys!" says Barbie. "I tried to send you my designs but I ended up crashing my laptop and Skipper’s, too. I need to get back to lost files and repair both of our laptops."

"It will go faster if Brian and I help," offers Steven.

This last line could be interpreted that Steven and Brian, not Barbie, can get this done faster.  I realize this is just one interpretation and the intention could be that if everyone works together, we can get it done faster.  We know in software engineering this may or may not be true – in form of the Mythical Man Month.  But in general, three people fixing two laptops might make this all go faster – debugging, troubleshooting, copying files and those sorts of things typically do turn out better with more people at the desk. 

But I’m still concerned about the fact that the less generous interpretation could be that boys can fix things; girls just come to them with their problems. So I’ve refactored this to say:

"We can all work on this together; it will be faster," says Steven.

The work continues with this on the next page:

"I got Skipper’s assignment from the hard drive!" exclaimed Steven.

"Fantastic!" says Barbie. "And her other files as well?"

"I got everything," says Steven. "Now let’s retrieve the files from your hard drive. Both laptops will be good is new in no time!"

It’s here where the dialogue really makes it look like Steven did all the work and Barbie waited anxiously for the results of his work. So I’ve refactored these to show Barbie being more engaged in the process.  Not just the Holder of the Compact Disc.

"We’ve got Skipper’s assignment from the hard drive!" exclaimed Steven.

"Fantastic!" says Barbie. "Let me get her other files as well!"

"Great! Now we’ve got everything," says Steven.

See how Barbie has a more engaged role here? No confusion about her fixing this problem, too.

One More Thing…

One of the key things that an engineer should do when disasters happen is to ensure that it never happens again.  One of the steps missing from this story is making sure Barbie and Skipper’s laptops are safe from future viruses. So I’ve added a new line to a passage:

The next morning Barbie gives her sister a big surprise. Skipper turns on your laptop – and it works!

"My lost assignment! cries Skipper. "You are just too cool, Barbie. You fixed my computer and saved my homework!

"I set up new security software on both laptops to make sure this doesn’t happen again," exclaims Barbie.

Skipper gives Barbie a huge hug.

You can’t just retrieve the files; you have to ensure those pesky viruses don’t come back.

How Do We Fix the Book, Though?


I fixed my copy by refactoring the printed pages.  You can do that, too. I’m sharing the Refactoring Computer Engineer Barbie PDF I created with the refactored dialogue.  Just print it on sticker paper and cut out the revised sections to update your copy of the book.  You might also want to head over to read that open letter to Random House, too.

I love my Technical Barbies and I want girls (and their parents) to have great role models in real life, not just with dolls action figures.  So books like this need the Best Practices in their writing.  I hope you do, too.

I have another post coming about the computer security parts of this story.  But for now, go fix your copy of this book.  Don’t leave it sitting around in production, waiting for someone to read it when it’s wrong.  Love your Data and Love your @Data_Model.

5 Naughty and Nice Ways to Love Your Data

Feb 14, 2013   //   by Karen Lopez   //   Blog, Data, Data Governance, Data Modeling  //  1 Comment


It’s Valentine’s Day evening in North America.  I’m guessing that means that you and a loved one are waiting for a table at your favourite ChiBeeFridayGardenTM.  Hopefully you’re not sitting in a crowded bar drinking sugary sweet margaritas that never came anywhere near a lime or real tequila.  But if you are, that also means you’re probably munching on some free chips and salsa.  Bueno.

As you know, I’m a data advocate…a data evangelist, even.  That means I want you to take care of your sweet snookums of data that you’ve entered into a commitment to love, honour and obey until the end of time.  Or at least until that next recruiter call comes.

So while working flying across Canada in my cubicle in the sky, I came up with these 5 tips for ensuring that your data feels loved, safe and warm.

1. Try some constraints.  I’m tired of seeing systems with no foreign key (FK) constraints or indexes on the data.  Vendors are especially straight-laced with their “we do all that enforcement in the application” answers as to why they don’t want to constrain their data.  That’s a subject of a future post. However, too many database designs lack even the most basic data quality rules.  There’s a whole lot of things we data professionals know about what makes for good (or good enough data).  Enforcing those rules as close as possible to the data is the best way to protect to that data.  To make it feel loved because it’s safe.

2. Be free. Don’t worry about backups.  What? No backups? No, that’s not what I said.  Don’t worry about backups; worry about restores.  You can have a perfect backup strategy in place and still not be able to restore because you’ve never tested that critical part of the process.  Sure, to restore there has to be a backup first, but too many people set that up and don’t realize that there’s another process out there deleting the backups, or destroying the tapes, or worse.  While you are at it, make sure you are monitoring the backups to see if they are actually working. Regular (and hopefully automated) restore testing will quickly point out failures in the backup and the restore strategy.

3. Put your data on a pedestal. I support systems with data that is more than a hundred years old. Over those decades, that data has been passed around between databases, systems, spreadsheets…well, you know how that works. Every professional who put their hands on that data had an opportunity to nurture it or to turn it into the broken, barely human data crying in a relation’s arms. There are certain data practices that make data less usable, less accurate and less strong. That weakness in the data translates in a general weakness in the entire system. That then translates into business weaknesses. Data last much longer than code. If you are optimizing database designs for the code, you may be harming it in a way that it can never love you back. Love it even on fast and agile projects.  Just enough design doesn’t mean no design; it means just enough to love it right.

4. Get familiar your data. Almost to the point of stalking it. You need to not only understand the structure of a database, but also what data is in it.  I can’t tell you how many times I’ve seen someone reverse engineer table and column names, then use only that information to analyze what data is contained in the database.  Big mistake.  Want to be surprised?  Go look at a bunch of columns called Notes or Description or Address Line 4 and see what you find.  I’d bet you a bag of naughty candy hearts that you’re going to find a brand new set of data that few people knew was held in that database.  You might even find credit card data, tax identifiers or insulting customer comments buried there.  I’ve seen all of that.   Data profiling is something you need to do for the life of a data structure.  Misuse of data structures happens more often than you think.

5. Cozy up with your team members. If you are data modeling or designing databases and you aren’t physically next to the people working with those designs, you’re missing out on a hundred opportunities a day to answer their questions, overhear their debates about the difference between Department and Division and generally not providing support for the project you delivered to them.  What? Those people work thousands of miles away?  You need to build a long distance relationships via Skype or GoToMeeting with these people.  You might even need to answer their questions in the middle of the night.  Just like in real life relationships.  The key is to send a message of availability and wiliness to help.  I’m pretty sure I’d better stop this analogy here, but you know what I mean.  You say your boss pulls you off a project as soon as version one of the data model is done and puts you on another one right away?  Well, there’s a name for that type of a boss.  I’ll stop here, too.

Your data really isn’t your data.  It belongs to your business users and some of it to customers.  When you don’t love your data enough, it knows.  And others will know, too.  So spend some time tomorrow ensuring that your data is loved, safe and warm.  It will do the same for you and your team.

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to by Email



UA-52726617-1 Secured By miniOrange