Sometimes the greatest life lessons can be inspired by other events. Perhaps a movie, song or something that inspires you to think differently about something that you do in life and at work. What I’ve learned, and want to share with you today, is that a lot of great strategies and lessons in IT and Systems Architecture can use the move Jaws as a parable.

Note: This is pretty much all inside humour for folks who’ve seen Jaws way too many times like myself

City Hands: Theory versus Implementation

When Quint first meets Hooper he comments that he has “city hands”. This is what we see in the industry sometimes when those of us who’ve been in the trenches first encounter the new staffer who has gathered most of their experience from theory, reading and limited lab time.

QUINT: Porkers! Talkin’ about porkers! Mr. Hooper. Just tie me a sheep shank.
HOOPER: I haven’t had to pass basic seamanship in a long time. You didn’t say how short you wanted it. How’s that?!
QUINT: Give me your hands. Dogfish? When you got a 5000 dollars net, you got 2000 dollars worth of fisherman. And along comes Mr. Whitey, by the time he’s finished with that net, it looks like a kiddy’s scissor class has cut it up for a paper doll! You got city hands, Mr. Hooper. You’ve been counting money all your life.

The lesson that comes from this is that, as we know, implementation will often differ from the plan or the theory due to unforeseen circumstances and limitations that couldn’t have been, or just weren’t accounted for in the early design. Implementation needs to be done from a solid design with the understanding that when the rubber hits the road that we may have to work a little to get things to follow the desired path.

It’s not that the theoretical knowledge isn’t valuable, but we need to temper our design theory with some real world implementation or even extensive lab deployment can help to strengthen the overall understanding of how systems really act when we need to bring them up in a real environment. The manuals only get you so far.

As the role of the seasoned IT guy, Quint has a little chuckle over Hooper’s plan to use a cage to get up close and personal with the Shark. If you’ve had the pleasure of being in a requirements gathering session, you have bumped into this before. You are often presented with what seem like entirely impossible or at the very least implausible requirements for a new system or process.

We’re Going to Need a Bigger Boat: Capacity Planning

This is probably one of the most famous lines from the movie, and ironically it was ad-libbed by Roy Scheider who plays the role of Chief Brody. Much like the Chief Brody figured out when he first saw the shark for himself, we are faced with this realization in our IT world quite often.

My old rule of thumb for capacity planning is take the original plan for growth, and multiply by 2.5 to get a longer term plan. With the cost of disk and memory dropping in recent years, this is an easier sell. Remember of course, that CPU sizing doesn’t follow that rule. In general we have to take heed with adding multiple CPUs because there are many more factors when adding CPU versus adding memory. This is a careful balance that your lab time will help you with.

While we can’t always deploy with a large system out of the gate, you should at least have a plan to be able to augment your system once it is live. Knowing whether you will hit limitations with growth is as important as having lots of space to begin with.

Those Beaches Will Be Open!: Fighting Deadlines

MARTIN: Larry, Larry, if we make an effort today, we might be able to save August.
MAYOR VAUGHN: August? Heh, for Christ’s sake tomorrow is the fourth of July! And we will be open for business. It’s gonna be one of the best summer we ever had! Now if you fellas are concerned about the beaches, you do whatever you have to , to make them safe. But those beaches will be open for this weekend!

Sound familiar? The business has set a launch date before the start of the project. It seems entirely reasonable, until scope creep and project delays push out the time-lines until they all start getting dangerously close to the launch date. Unfortunately with the traditional waterfall project methodology, we sometimes have trouble backing away from features and enhancements which impact the deliver-ability of the project..

Agile project methodology and Agile development can alleviate this a little better with shorter sprints and features being managed and dropped as needed as each sprint arrives. The end result of any project is that you may be faced with 23 hour days to hit the launch target if it is set in stone.

The moral of this story is to track your implementation and stay aggressive on limiting scope creep. Deadlines based on dates and not features can be the bane of any IT staffer’s existence and certainly makes our jobs more difficult.

You Knew All Those Things! *slap*: Disclosure

MRS. KINTNER: I just found out, that the girl got killed here last week, and you knew it! You knew there was a shark out there! You knew it was dangerous! But you let people go swimming anyway?!You knew all those things!

When we have an awareness of potential danger or design flaws in a technology project, we have a responsibility to notify the business sponsor and our own management of those issues. This isn’t just so that we can have that “I told you so” moment if issues arise, but a safeguard for the project to highlight potential problems. While we all know that our warnings often slip through the cracks and may not get the attention we hope they would, it is still an absolute necessity to voice valid concerns as early as possible, and to the right audience.

Hopefully, if we do encounter that moment when a system fails despite our warnings to the business owner, that their reaction is a little less painful that what Mrs. Kintner doles out to Chief Brody.

He Can’t Stay Down With Three Barrels: Performance Testing

QUINT: He can’t stay down with three barrels on him, not with three barrels he can’t.
CHIEF BRODY: What about us?
QUINT: Hooper, get the pump outta the locker in front of you, will you?
CHIEF BRODY: We’re gonna sink aren’t we?

Performance testing is not just something we do for fun. It is designed to give predictive results for the launch and design of any system. We often forego testing in a project due to the time constraints and lack of understanding of the performance requirements of the new system.

Experience tells us what we should expect, but the only way to provide comfort to our business sponsor and to our IT management teams is to gather real results before we put our system into production. Nobody wants to be at a launch party to then watch everyone’s phones and pagers light up that the system just ground to a halt because of load.

An often misunderstood area of IT, I highly recommend that you invest time in learning about I/O performance, bottleneck identification and testing tools for web and client/server systems. There are some great free tools out there, and that knowledge can change your status from scapegoat to hero if we do our part to design for high volume scenarios at the onset.

The U.S.S. Indianapolis scene: How IT Community Helps You Learn

Sometimes the greatest experience comes from sharing war stories with others in your industry. Comparing scars and horror stories of how implementations went completely sideways, passing along tips learned in the hard way. You can get great value by participating in IT communities like the VMware User Group (VMUG) and other IT community groups.

It can be a great learning experience just to be involved in discussions about how real product and infrastructure deployments have gone. It can give you an insight into the pitfalls and good methods to do many things. You can learn significant amounts about technology just by being in the right crowd. Don’t be afraid to ask questions and be a good listener. One day you will have your very own U.S.S. Indianapolis version of an IT story to share with a new sysadmin.