Image may be NSFW.
Clik here to view.
I tend to take real-life events and correlate them to computational scenarios. It’s a hazard of being a technical professional, I suppose.
In the United States, it’s kind of a law that you have to move your family across the country at least once in your life. I’ve done it a lot – when I was young, then when I was in the military (even cross-continent moves a few times) and recently I decided to move again. I loaded up a U-Haul trailer, hitched it to my pickup truck, put the two cats in pet carriers, opened the door for my wife and drove from Covington Washington, to Safety Harbor Florida – a distance of 3,723.2 miles.
The area surrounding my Washington home is near the Cascade mountain range, and our circumstances dictated that we move in the winter. We decided against going directly across the Snoqualmie Pass on Interstate 90, as that would take us across the plains states, which were (and are, as of this writing) undergoing one of the worst winters in some time. Instead, we drove south along Interstate 5 to California, then at Los Angeles took Interstate 10 through Arizona, New Mexico, Texas, Louisiana, Mississippi, Alabama, and then around the panhandle of Florida to Tampa.
The trip was fraught with peril, and we had many adventures along the way. Those adventures map quite well to software projects in general, and cloud computing software projects in specific.
Lesson 1: Planning is essential, plans are useless
We planned very carefully. I’m a bit of a “Type-A” personality, so I tend to over-plan…well, everything. I planned the routes. I planned the emergency routes. I planned what we would do if something took more time than we thought, and what to do if it took less time than we thought. We planned for everything from snacks to CD’s, from MiFi devices to in-car converters for power.
And of course almost nothing went to plan. The first three hours outside of Seattle, near Portland Oregon, we hit an ice-storm – the biggest they’d had in decades. The (highly overloaded) trailer hit a patch of ice, and took the truck across three lanes of traffic into a guardrail. I managed to patch up the truck (on the Interstate, no less) to a drivable state and then limped to the nearest hotel. They closed Interstate 5, because they had 600 wrecks between Portland and Salem. We got stuck for 3 days at that hotel until the roads cleared. Our plans and timelines evaporated.
Cloud projects can be like that. If you’re designing one for the first time, you’re headed in an unknown (for you) area. But that shouldn’t prevent you from planning. You see, planning – even when it doesn’t work out like you thought it would – leads to preparation, and preparation will help you pivot when things don’t go as you want. When you’re creating your specifications, do a “pre-mortem” – an exercise where you imagine the project failing, and what you’ll do if it does. It will help you identify processes and procedures you can fall back on.
Lesson 2: Prepare well – you’ll probably need the emergency stuff
As the truck careened across the highway, I was glad that we had packed the way we did. The cats were secure, we had our seatbelts on, we were moving pretty slowly. As wrecks go, this was a mild one. I had put two things in the (very tight) cab space: tools, and orange safety vests (we wear them when we ride our motorcycles). We needed both, three hours into the trip.
After we finally got out of Portland, we crossed many mountain ranges. The truck was overloaded as well as the trailer (did I mention that?) and we had to move VERY slowly up the mountains, even with a full-sized V8 engine. 18-wheel Trucks were passing me. It was embarrassing.
The next day we got up in Sacramento, California, where the roads are essentially made from pot-holes so deep you need to turn your headlights on to get out of them, periodically connected with thin strands of asphalt. The trailer, being a bit overloaded, snapped the ball of the trailer hitch off, and since there was no shoulder (California roads are not designed for anyone to have any problems on them) I had to:
- Position Marjorie with her orange vest on behind the truck to wave rush traffic over so as not to wreck the truck any further
- Run across the highway
- Climb a 6’ fence
- Run to an “Ace Hardware” store, startling the staff who watched me vault a fence and run into their establishment
- Purchase a replacement ball (they had one, and only one, but thank heavens they had one)
- Run back, vault the fence
- Jack up the trailer
- Replace the ball on the hitch
- Micro-back up the truck multiple times underneath the (fully laden, un-movable) trailer (Marjorie was a little busy and could not help me)
- Lower the jack
- Retrieve Marjorie (who was a really good sport about all this, considering. Well, at least we’re speaking again. Mostly.)
- Re-enter rush-hour traffic
- Continue on to Los Angeles, hitting it at rush hour instead of the planned noon
The correlation here to software projects here is that you should invest in, spend time on, and have ready the emergency things you need in case the project goes wrong. Not just the whole thing, but each part. It took up valuable space to have the tools in the cab, and orange vests are kind of…weird looking. But having them saved us, quite literally. You should think the steps through and put systems into place if things go wrong – retry logic, local caching in case the line is down, and anything else you can think of. Odds are you’ll need them.
Lesson 3: Everything takes longer and costs more than you thought
It goes without saying (but of course I’ll say it anyway) that our schedule was blown to bits. What I had planned to take 5 days took 8. I had to drive slowly (we were overloaded heavily) and of course those pesky ice-storms, bad roads, and many other factors made my average speed 43.5 miles per hour. Even with driving 14-16 hour days, it was really delayed. Interestingly, because of the very weather we were trying to avoid, trucking and other traffic had been re-routed to – wait for it – Interstate 10. Essentially it was a 5-day rush hour, all day, every day.
I didn’t know we would stay in the hotel for three days, need to buy chains for the truck and the trailer, fix a ball, get 10.7 miles per gallon (we were a bit overloaded so that trashed my planned gas mileage) or the other expenses we incurred. But because we had planned for things to go wrong, I had the money handy. I even had more cash than Marjorie normally allows me to carry in case we had to use that to get what we needed.
In software, cost and time estimation is really hard to get right. In the case of something new, make your best generous estimate, and then double it. Don’t let people pressure you into shortening it – you’ll regret it later. No, this isn’t to say cloud projects are costly or risky – this holds true for any project, and yet I see the same mistakes being made in this area over and over.
Lesson 4: Keep a positive, long-term view
So what have you learned from my tale? Not to move yourself across country in the winter with a heavily overloaded truck and trailer? Perhaps. But even with the extended time and cost, it was cheaper and faster for us to do it ourselves – we did the numbers, and with all the problems it was still 1/5th the cost of having someone else do it and us flying the cats with us home. And since Marjorie is talking to me again, we’re closer. (Actually, she was amazing the whole trip, and super-supportive of her risk-loving husband. We talked the whole time, mostly “LOOK OUT IS THAT AN ICE PATCH SLOW DOWN THAT WALL IS REALLY CLOSE YOU MISSED THE EXIT I WANT OFF”)
You might think you shouldn’t embark on a cloud project – it’s too new, too risky, and there will be too many problems. But you’ll miss out. And your company will miss out. So plan. Get the truck – maybe don’t put as many requirements on your project as you might – those roads can be plenty icy. But when you see the sun set over the water as you pull into your new driveway in 85-degree winter weather, you’ll be glad you did it.
Image may be NSFW.Clik here to view.