I just finished the best Software Project Management book I have ever read. It covered proper planning, requirements gathering, resource management, inter-organizational communication, and even discussed the immeasurable factor of individual effort. The book’s title is ‘A Bridge too Far’ by Cornelius Ryan. The book is actually a historical account of “Operation Market-Garden” which was an attack by the Allied forces against Nazi Germany in World War II.

First let me say that I am not comparing Software Development to War. I do appreciate the difference between losing one’s job and losing one’s life. But as I was reading the book, the parallels between the job of a project manager preparing for, managing, and executing a large project are not unlike that of the job of a General’s planning staff preparing for a major offensive.

Operation Market-Garden was a combined ground and paratrooper attack into The Netherlands by the Allies a few months after the invasion of Normandy. Things seemed to be going well for the Allies in the months after D-Day and the Allied Generals became confident that they could launch a lightening strike that would end the war sooner rather than later. The operation seemed simple, Airborne paratroopers would be dropped deep in Nazi territory and would capture key bridges along a route into The Netherlands. A ground offensive would quickly follow using the bridges that were captured by the paratroopers to get almost all the way to Germany’s borders. The short version of the story is that the ground offensive never caught up to the paratroopers and the offensive didn’t succeed.

Reading the historical account, with the benefit of hindsight, it became obvious that the Allied Generals underestimated the difficulty of the task. The offensive scope was too big for the resources on hand and perfect execution of all the individual engagements was required. The schedule the Generals developed was impossible to keep and schedule slips meant death for many of the soldiers. Communications between elements of the units involved was critical but did not occur. However, because of heroic actions of some individuals and personal sacrifice of many, the offensive almost succeeded.

In the early stages of a project, setting realistic goals, and not putting on blinders as to the quantity and quality of your resources are key to a projects success. Going on the assumptions that the ‘development weather’ will always be perfect, communications will always work, and that all tasks will be completed on schedule is a recipe for disaster. And you can’t always plan on individual heroics to save a project.

I usually try to inject some levity into my posts, but not this one. 17,000 Allied soldiers, 13,000 German soldiers, and 10,000 civilians were killed, missing, or wounded as a result of this failed offensive.

That is a heck of a strange title for a hosting company blog post.
It was, however, a great title for a Master’s thesis. Bear with me though and I’ll put it together.

Once upon a time, I spent many a day (evening, night, whatever) in the basement of the Bright building at Texas A&M blasting ultrasonic waves at samples of composite materials and measuring the energy output on the other side. What we found was that if you hit the right frequency that made the little particles resonate, then a lot more energy was transmitted through the material¹. But sending a lot of energy at the wrong frequency didn’t do any good at all and most of the energy was absorbed. After a while, using the experimental data, we learned how to predict what frequencies transmitted the most energy.

Developing projects for a hosting company is pretty much the same. You can spend a lot of energy writing code and developing products, but if you don’t produce something that resonates with the customer, no matter how much energy you put into it, you aren’t going to get the results out of the other side. Having been in software development in the hosting industry for quite a while now, I have worked on projects that resonated with customers and a unfortunately on a few that didn’t. The trick is to collect enough data before you start by using a mix of experience and customer interaction to predict what will resonate, and what won’t.

See, I brought it all together and I get to tell myself that I still use my master’s degree.

¹I way oversimplfied this. My apologies to Dr. V. Kinra.

I’m spoiled. Really, really spoiled. I have a test lab full of servers to play with about thirty paces away from my office. Most of them have KVM over IP on a daughtercard. When I need to jam an OS on a server or manage to lock myself out by screwing up a network config, do you think I stand up and take a short walk? Nope. I fire up the KVM/IP and take care of business from my comfy office chair.

Let’s see how old the audience is. Raise your hand if you ever had to yell into a phone telling a datacenter tech what to type.

“’S’ as in Sam, ‘H’ as in Harry, ‘O’ as in Oscar, ‘W’ as in Wally, SPACE, ‘D’ as in David, ‘E’ as in Edward, ‘V’ as in Victor, ‘I’ as in Isabel, ‘C’ as in Charlie, ‘E’ as in Edward, ENTER” (extra credit to whoever can name the OS without using a search engine or reading ahead).

For some of you this is a recent event, but there will come a day when our IT generation can regale the youngsters with stories of “When I first started in IT, we didn’t have this fancy KVM stuff you kids have today…”.

KVM over IP isn’t exactly brand new. It has been around for a few years starting with external devices hanging off the back of the server. But it is becoming much more common to find daughtercards from your favorite motherboard manufacturer with this capability. The motherboard suppliers have already added other server control technologies like IPMI and iAMT to the motherboard. I wonder how long until KVM over IP makes the jump from the optional daughtercard to coming standard on the motherboard? I’ll bet we’ll see it before you can spell VMS.

Nathan Day

CTO