In 1995, there were approximately 5 million mobile connections. A short 15 years later, that number is closer to 5 billion a number that’s rapidly approaching and will handily surpass the actual population of the planet. Look around, and look on your person, it’s likely you’ll find a smart phone, maybe a tablet or even an older MP3 player. This isn’t even counting such antiquated computing resource like a laptop, and it’s easy to see why the calculation is going to average over four such devices per person. To say there will be growth in mobile is a bit of an understatement, once you consider all the other “widgets” yet to come — from embedding into appliances to health-related devices, like glucose meters, heart monitors or even plain old thermometers. My point is, lots of mobile (platforms) invites for lots of mobile apps. Seems like daily, that I hear about someone becoming a mobile application developer.
Want to find out if an engineer performance tested their application? Tell them to do one thing for you: Make it crash. That’s right, bring the network traffic to a crawl; force it to run out of memory; take away disk space. Have them demonstrate that they know the limits of their application so well, they can make it fall over at will. If they’re bad ass, they’ll whip out a test script and start it up. In a few minutes, the application should crash in a predictable way — predictable if the application is well designed. But really, my point here is to try to make it crash but not be able to.
Mobile is changing our lives. We now have nearly un-dreamt amount of computing resources in our pockets, and it has deeply enriched our day to day experiences, especially for the current consumption-centric life styles we lead. But, companies seem to be resistant in adopting the same outlook, and are in fact, not embracing the BYOD movement. MP3 players were OK, but corporate IT seems so resistant about hooking up your Samsung Galaxy Nexus for Email, or adding you to the WiFi network. Don’t they get the value? That’s just the business being slow and monolithic and missing out on the wonderful opportunities, right? Not so fast.
Yesterday morning, along with hundreds of thousands others online, I watched the live HD video feed of the Mars Science Laboratory Curiosity successfully touch down at Gale Crater as planned/designed. It is a significant milestone, and quite the hallmark of success for a complicated mission. I couldn’t help but think about the dichotomy that is NASA — the rare mix of size, bureaucracy and performance. Over the years, we’ve witnessed their triumphs and their failures, as well as some epic recoveries from disastrous missteps that plague the largest of enterprises. One observation became clear to me, as I listened to the debriefing panel: if you’re not making something better than you’re not relevant.
A lot has been written about execution. Yet it clearly remains a challenge and an elusive goal to both individuals and teams. I could start espousing my own theories of execution, but I have no desire to add to the stream of management mumbo-jumbo regarding roles, responsibilities, metrics and results. Make no mistake, it is precisely the desire for results — the point B, in going from point A to point B — that leads us to examine and question execution. Too often, even capable people [and teams] focus on making history, when the focus should be on making impact.
True operation mavens know that downtime is inevitable. It’s going to happen, despite your best efforts. A blip, a stumble, some cable will get cut. Increasing the “nines” carries quite the price tag, and may not be the best way to maximize ROI. The plans for disaster recovery needs to be balanced, so that focus isn’t solely on the prevention of catastrophes. Equally important, is the rapid recovery for business continuance. Because that is the true goal of uptime — to serve pages, apps and data, to provide for the customers, and continue the revenue stream. This is no longer an insurmountable task, given the resources and knowledge at hand.
Hand me your credit card, you idiot. No, when things start running slowly don’t just blame the hardware. Yes, hardware can affect performance, but if you just did a release, and at the same time you started to see a spike in system resources without a spike in load, the problem is in your software. “But hardware is cheap! We can just buy more hardware!” or the more contemporary, “Cloud instances are cheap! We can just spin up more instances!” You twit.