I’m writing this post from my living room, don’t worry. A recent last-minute trip to replenish the household toilet paper supply had me thinking of this illustration. So…
I’m a big fan of finding lessons for the day job from everyday life – call them illustrations, if you want. I’ve found inspiration preparing for planting asparagus, stacking wood way later in the season than I should, playing blocks with the kids, or while in the shower, to name a handful of places. There is also an inspiration to be found in another area of the bathroom, I think… Near the toilet. Seriously! Here are some of the Database Technologist lessons that revolve around toilet paper/toilet tissue/bathroom wipes/ whatever you want to call the stuff. (These points may come off a bit crass, but I think we all understand how a bathroom works. This is one common denominator, even if it’s imagery we don’t necessarily look for in a technology post)
1.) Look Before You Sit
Pretty simple. If you have kids, this lesson is one you know about… Heck, who I am kidding. You’ve been here before too; we don’t need to blame the kids… It’s a good idea to check for a couple of things before you sit… Primarily for the presence of toilet paper (though, as one of my kids found out – it’s also a good idea to check that the seat is not in the upright position)… Let’s just say you quickly realize the error of your ways when you forget this lesson.
It happens all the time in our day jobs, though. Not making sure you have everything you need to be lined up. Not planning for the right design, not thinking about the future, not putting in error checking. Not planning for deployment. At some point, a project is going to go live. Right? Make sure you’ve thought of the end results, the finished product, and you’ve built a process and are ready to see it through to the end. Otherwise, this next lesson may bite you:
2.) Take Care of Business or Get Off The Pot
When you are on that project that is fledgling and never gets off the ground – your legs don’t fall asleep, you just get frustrated, and no one wins. You need to execute. Your team needs to execute. Hopefully, you have great project managers who have proper go-live plans, have checklists and milestone meetings, and listen to their Dev teams. Even if you don’t? You need to be a voice of reason. I say the DBA is the only one at a company who cares for their data. I like to think DBA really stands for Database Advocate – and you need to act as it does stand for that! That doesn’t, however, mean that you can just throw useless red tape at every request… It means you have to keep the machine moving and execute correctly, calmly, with all of the facts, but as efficiently as you can. Or you shouldn’t even be trying. Don’t be afraid to say, “We can’t go because of ____” and don’t be afraid to say, “let’s stop talking about this fix, and let’s implement it. Here is why”.
3.) Garbage In Garbage Out
Spend a week eating garbage, fast food, and not taking care of health? Don’t be surprised at the results… Rush the database design phase? Rush the application design phase? Don’t be surprised by the results. The build and design phases are as important, if not more important, than later phases of projects. If you invest in good quality upfront, the ends are higher quality. As a consultant, I’ve worked on more performance-related issues on systems that rushed through the design phase and made a lot of “it works fine today” type assumptions than systems that were well planned, had a future focus in mind, and spent serious time in the design phase. I’m not saying it can’t happen and will never happen – I’m just saying that rush jobs upfront seem less expensive and like a great idea. They are less expensive in the short run but often cost much more in the long run. Watch carefully what goes into your designs and products, and you’ll be pleased with the results.
4.) Assume Scarcity
Let me see if I can get this lesson out right… Imagine two different bathrooms. Imagine you didn’t follow the first bit of advice (check before you sit)… In bathroom #1 there is an overabundance of toilet paper… In bathroom #2 there is a single roll with hardly any left on the roll. Everything else is the same. I bet you anything that in bathroom 1, there is likely not a ton of thought into how much is used. In bathroom 2? Care is taken, and conservation is applied. It will either be just the right amount, or there may even be some left…
Do your database development the same way… Pretend you are on your last roll of toilet paper all the time… You are going to do what you can to make it work, right? Do the same thing with your code.. Look at your IO stats (SET STATISTICS IO ON), look at your query plans. Understand each query’s performance with the dataset you have, try to make your development data sets be production-like – even production with extra data simulating successful growth. Be miserly, use conservation and make your code shine even when you have the biggest roll of toilet paper you’ve ever had – I mean the biggest development server you’d ever imagine, and everything finishes incredibly fast no matter how poorly it’s coded. You see – many of my performance tuning clients will tell you that “it worked fine in development, or production before we got busy and this site or product really took off. Once we got more data and more history, we started having issues.” They had issues initially, but they didn’t think they’d ever run out of resources, so they didn’t care how much they had to use, don’t do that!
5.) A Plumber is Best Called at Design Time
No one wants to have to make an emergency call to a plumber. Especially when we are talking about this room of the house, it’s expensive. It’s awkward, and it’s never a convenient time.
Consultants are the same way. I’ll be more than happy to come in as a SQL Server consultant at any phase of your project, and I’m pretty sure that I’ll help you make a difference in most situations – or give you your money back, frankly – but we’ll all enjoy the process better if we are talking at design time. Before all of the drainage pipes is already laid, the inspector has come and told you that your sewer pipes are inverted or don’t have the right angle. Or worst – your inspector didn’t tell you, and you moved in. My father-in-law is a plumber; he’s shared some horror stories with me… It’s easier to move things around before the basement is finished. It’s easier to fix design problems before you’ve built a bunch onto your database, too. And you’ll often save time and money by spending time and money upfront – it’s why I enjoy eating that asparagus each spring lately.
That’s enough for one post. There are other lessons, but those are the ones that come to mind first. Dare I ask what other technology lessons I missed in this seldom talked about room of the house?
7 thoughts on “5 Database Lessons From The Bathroom…”
Really like this article Mike. Well played sir.
Thanks Chris 🙂
Publish (and enforce) standards: There will always be at least 1 roll of TP in reserve in BOTH bathrooms, and if you are replenishing TP reserves there will be no less than 3 rolls. 🙂
Funny how this article started making me considering things. You should also have a regular maintenance plan in place. Flushing often makes for a much smoother operation than waiting for “buildup”.
All sorts of analogies or illustrations around the house. Once you start on that mindset, the ideas keep flowing. 🙂 Both of your thoughts are excellent.
Of course, if you have 4 family members and 6 guests, you would be wise to check the TP supply in both bathrooms early and often. Similarly, if you have many users making demands on the database, you should be keeping a close eye on performance … you might even want to considered adding an additional bathroom/copy of the database fot special users (e.g. reports) .