Regular readers of this blog know that I’m a huge fan of the One Laptop Per Child (OLPC) project and the XO laptop. A previous OLPC related post may be found here. As a result I follow the OLPC News blog which recently had this great article by 16-year-old Derek Chan on his experience with a small scale OLPC implementation in Kenya.
My name is Derek Chan, I’m 16 years old, and I was part of Mark Battley’s team of high school students from Upper Canada College that initiated a small scale OLPC implementation at the Ntugi Day Secondary School.
Part of our goal was to provide Ntugi with power for their initial complement of 8 XOs and 2 Cradlepoint PHS300s at a school that had no access to the country’s power grid.
In addition to this being a very well written piece about an extremely fascinating project, Derek enumerates some lessons learned that are directly applicable to any Infrastructure and Integration project. Especially security infrastructure projects like say a Network Access Control (NAC) or Enterprise Single Sign On (SSO) project. Just replace the word “school” with “enterprise” or “business“.
Ultimately, we were successful, but not without missteps and failures along the way. We did lots of things right, but we made a few newbie errors. Here’s what we learned!
- Learn as much as you can about your destination school’s physical resources.
- Don’t assume that tests in the lab will duplicate conditions in the field.
- Read all the relevant blogs, forums and bulletin boards before implementing.
- Don’t underestimate the sophistication of local technology and expertise at your destination.
Let’s think about each of these in turn, much as Derek did in his post.
Learn as much as you can about your destination physical resources.
Who hasn’t heard the horror stories from the installation team that just tried to add “one more appliance” to the customer’s data center, only to find out that the power or cooling or rack space just wasn’t there. Always verify ahead of implementation that the destination has all of the physical resources required by your hardware, all of the compute resources required by your software, and all of the network resources, including IP address space, required to connect it all together. An actual visit to the site by your Systems Engineers is a really great idea. Never assume that the destination is a “typical” configuration or that the customer knows the difference.
Don’t assume that tests in the lab will duplicate conditions in the field.
Boy Howdy! This assumption ranks right up there with “no customer would ever do that” as a surefire path to failure. The point is that the lab, by definition, is an artificial environment. Sure our QA engineers do the best job they can to simulate a real world environment, but the key word here is simulate. It’s pretty hard to simulate things like network latencies or ATM noise in the lab. Remember your lab techs are good, not god. What a difference that “o” makes.
Read all the relevant blogs, forums and bulletin boards before implementing.
Not that this has ever happened to me, mind you, but I’ve heard of engineers that actually believe the promo literature and design the system around that, assuming that all the details are handled. I mean how much difference can there be between Server 2K3 and Server 2K3 R2? Yeah. Just do the homework. That’s called “due diligence” in business speak.
Don’t underestimate the sophistication of local technology and expertise at your destination.
As engineers we always like to think we’re way smarter than the mere mortals we tolerate in our presence. But never fool yourself into believing that you can understand the ins and outs of a customer’s infrastructure as well as they do. You may think they are yokels, but they are yokels with way more relevant experience than you. And they are the ones who control your payday. Just suck it up and let them make it easier (or possible) for the project to succeed.
So there you have it. Excellent advice from a 16-year-old who has already learned some important lessons. Well done Derek.
