Alphabet Blocks and a Solid Foundation

Continuing in the theme from last week’s post correlating the DBAs role to aspects of various careers (Pilots, Chefs and Doctors) an illustration came to me this past weekend.

I was playing blocks with my 1 year old son. The game with him consists of me trying to hold him back for as long as possible while I build a tower with those alphabet blocks as high as I can. I then stop holding him back and the tower gleefully comes down with the blocks flying across the room. He loves it (so do I, he makes the best expressions while tearing it down).

I play a second part of the game myself and try to beat the number of blocks from the last attempt. That’s when two illustrations hit me. I do admit, they are simple but a lot of projects seem to miss the mark on them.

Foundation is everything 

I am building these block towers on a carpet, so I have stability going against me right off the bat. If I build the tower in a row that only has one column (single block stacked on top of another single block) it teeters pretty early and I can’t get great height too easily. If I start out with a base (sometimes a one block high 4×4 set of blocks with a 3×3 set on top then the single stack going up) I can go much higher and can even add the blocks to the single stack quicker. Sure it took me a few extra seconds to build that base (those seconds matter when you are holding back a strong and determined son!) but it was worth it in the quality of the crash because of the higher tower.

It’s the same for us:

• If you don’t take time to figure out what the users really want to do and just build something based on shoddy requirements and assumptions you’ll get what you paid for; low up front project startup costs, high costs when the scope changes or you miss the mark completely. Talk with the users, understand the business process and reason for what you are delivering. Have a conversation, not an order taking/giving session.
• Go ahead, rush through the setup of that production cluster, I dare you. You might have it ready ahead of schedule (or even on schedule if it is unrealistic) but you will end up burning through a lot more time when you have to fix it multiple times (after it’s live with your face red each time). Follow a repeatable process, learn and follow best practices, understand what you are working with and seek understanding if you don’t.
• I can vividly remember reading Inside SQL Server 2000 for the first time. I was reading it for “pleasure” and when I got to the performance chapter I loved what Kalen said. (Paraphrasing: “If you went straight to this chapter looking for performance help, you are doing it wrong, you need to understand all the chapters before this one”). I read that in the early middle part of my career and it has stuck with me. If you don’t design for performance you will be in a never ending reactive battle for performance the rest of the implementation’s life.

Small mistakes magnify themselves when you add scale

If I am making a tower with 4 blocks, I can put them on top of each other fairly quickly. They can be completely out of alignment and still be sturdy (until William gets his hands on them). Once I add that fifth or sixth block the tower comes crashing down without any destructive pleasure from the boy.

If I take a little more time but still have them off centered a bit, I can add more blocks but eventually I am adding each block deliberately off center depending on which way my tower is listing. The tower will never grow to the height it could have with a proper base and attention to detail in the beginning. This is fine if I only wanted to go so high and get minor laughter from my little Godzilla. Not so great if I wanted to get admiration from my wife or three year old (“look how high this one is!!!”) or elicit maximum laughs. The tower just won’t scale and it is destined for a gravity fall.

Talk to people who target shoot for a living and they’ll tell you the same thing. At 5 yards a training flaw will probably not show up. Go out to 25, 50 yards or more and what seemed like a little “oops” becomes a huge dissapointment. Mistakes always get magnified as you add scale.

You’ve seen it:

• Rush a system out to production after doing a test with a couple users. Everything seemed fine, maybe a few queries with higher than desired reads but no big deal. The problem is: production has a lot more than a couple users and you now have serious production issues. Test to the scale you will release to, look at performance problems with future scale in mind.
• How many times have you said something that sounds like this, “Well it’s not perfect but we’re too busy to get it just right.. We’ll fix it later”. Only to find that later either never comes or is too far away. Aim for perfection (no we won’t ever release perfect software but have an incredibly low tolerance for what “Production Ready” means), make sure your statement jives with your expected user load.
• Pay attention to detail. It’s not normally the huge glaring mistakes that cause all of the headaches. We are normally competent enough to notice those and they normally pop up even in smaller unit tests. It’s the little problems adding up together that create those weekend killing troubleshooting scenarios. I don’t know about you but I want to know that the person working the line when my vehicle went through made sure each little screw was there (and tight). Sweat the small stuff, don’t treat any part of a task with apathy as that’s the piece that will come back at you with vengeance.
  

There are plenty of other lessons to be gained from playing with blocks with my son and daughter:

• Those little wooden alphabet blocks REALLY hurt when you step on them with bare feet… Picking up after yourself can make a huge difference (My wife will tell you I am still working on that lesson, but I tend to at least be good about picking these blocks up or moving them to one side)
• Have fun! It’s a riot watching his reaction and the noises/expressions he makes (curls his nose up and snorts) are priceless.
• Don’t throw a block in front of the kids. They seem to see that as a lesson of something they can (and should) do… Oops.