Saturday, July 28, 2007

The Upper Right Corner

While chatting with a friend in the business, the topic of graphs in marketing data came up. I put my "unix sysadmin cynic marketing and sales are all evil" hat on and belted out this snarky comment:

"You always go with the guys in the upper right corner."

"What does the upper right corner mean?"

"Who knows. But when has the upper right corner steered you wrong?"

The discussion sparked the memory of the first graph I made as a marketing guy. Technically, my position was titled "Director of Product Performance and Benchmarking" - but it was really just technical marketing without the marketing name. Being a fresh engineering convert, I was still a little unclear on my role and the expected material I was supposed to produce so I did what I always did: wing it.

The first order I got was to get accurate performance numbers on the product. So after getting a lab setup, I proceeded to run a performance test - the first one done outside of engineering's auspices. The data I collected was requests/second vs. object size. In other words, how many times could I ask for a file of a given size per second. The data was great! The product screamed at 20,000 requests/sec for 1k files. As expected, the number of requests/sec that could be made went down as the file sizes grew. The result was a graph that sloped from the top left to the bottom right.

Proud of my first round of data, I wrote it up and sent it to a few sales guys. Chaos promptly ensued.

"I can't sell this!"

"When is it going to be fixed?"

"Is this in all shipping versions?"

One of the sales guys that I had a better relationship with swung by my office and asked for details. I tried to explain it to him - the graph was a good thing! He countered, "Look, I really don't get what you just said. All I know is that performance is going down and I can't sell this."

The conversation was a real eye opener.

With the cc-list growing exponentially and a small posse with fire laden torches looking for who was at fault for this catastrophe, I scrambled to find a solution. I couldn't articulate why at the moment, all I knew was that I had to make the same data go up. Up is good. Up is always good...

While conjuring spirits of graphs past, I found inspiration in the configuring panel of the testing tool - clients. How many clients are needed to generate how much load? It was a problem we struggled with in getting the lab setup with enough machines together to generate enough load in the first place. With more clients, there was more load. More load was a higher number. More load was a graph that went up.

Taking the data and reformatting it as requests/sec vs. clients, I graphed pure happiness. A line that went from the lower left to the upper right -- a line that went up. Up, after all, is goodness. A cut, paste, and resend later, peace returned on the email trail. Torches were extinguished. The posse dispersed. Ever since then, I've fixed countless graphs to make sure they go up.

Up, after all, is good.

Sunday, July 15, 2007

Who is MY David Pogue?

The networking world's press is in some serious turmoil these days. No terrible surprise here - it's been something that has been in the works for quite some time now. Any observant reader has probably noticed that some long time names have outright left the industry. Niche markets are especially struggling with very little in the way of print. The future is clearly going to be defined by web driven content.

So who is our new David Pogue of networking?

It's actually quite ironic that the networking industry itself has been so slow to establish online personalities and create a hierarchy of sorts. There has simply been no real set of people who are setting the tone leaving it to be a free for all. Of course, I'm sure it's a matter of time before a new set of people emerge, but the fact that we aren't already there no speaks volumes.

Thursday, July 12, 2007

Application Streaming on Linux

On the weekend before July 4th, I wanted to needed to install a Perl module so I could play with RSS feeds - just a little "left brain" side project. Other programs that parse RSS feeds would use the same module. Over the next several days, I unraveled some ugly details...

- Because FOSS developers only test on their own machines, they make some grand assumptions about what the base system has and thus don't list out *all* of their dependencies, just the ones that they noticed. These assumptions are often wrong on other distributions or slightly older distributions.

- The step from large FOSS projects like Apache to the next rung down is a doozy. They have a significant number of dependencies including numerous small projects. These small projects are not nearly as well tested, thus while the top line project may work well enough, the dependencies are a crap shoot.

- It's not hard to hit an "artery of dependencies". If one library/module/app depends on a major package being updated, it's possible to end up with a slew of large system level upgrades. E.g., Updating perl requires a new version of FreeType which breaks older versions of ImageMagick (depended on by countless web apps). New versions of ImageMagick needs a specific feature of the latest X-Windows which needs updated text processing tools to build its documentation files. The updated docs text processing tools need an updated version of gcc/g++ and XML libraries. The XML libraries need a newer version of libtools, etc. In short, it takes "DLL Hell" to a whole new level.

- While this specific experience was on FreeBSD 4.9, the issues clearly apply to anything where a new distro comes out and not everyone upgrades. Friends who use Linux as a desktop confirmed that they regularly run into these things. While they don't get grumpy about a lost hour hitting the apt-get utility, I believe that the same task thrown to an enterprise IT administrator would be a frustrating day+ ordeal. Take one of the many CMS implementations available that are largely written in either Perl or PHP. New version of the CMS which fixes a critical bug? You may find that it needs a new module to go with it.... Rinse and Repeat.

On the Microsoft side of the world, application streaming is coming of age. Microsoft's acquisition of Softricity and Citrix's Presentation Server 4.5 are the leading contenders with a number of similar plays from startups like AppStream and Ardence. The market is completely open for Linux. Right now, virtual machines are being used in a similar way, but it will not be long before IT administrators realize that they don't want a virtual machine on a per-application basis, especially if they need two applications on the same machine to work with one another.

Saturday, July 07, 2007

Does Green IT Really Impact Bottom Line Green?

Articles like this one from BusinessWeek are abound. Big dollars are to be saved by by going green in the datacenter and every company's operations group should be taking a careful look at their own usage.

I'm generally suspicious of this kind of math because I've used it myself. Nice, careful selection of numbers and wham-o... big dollar savings that are hard to ignore. Wes Wasson referred to these kinds of numbers as a "BHAC" - Big Hairy Audacious Claim. The irony, he once noted, was that the more extravagant they get, the less they get questioned. To his credit, Wes stuck to numbers he could back up but being a good marketeer, he was quick to identify gems when he saw them.

I did some recent work with respect to power savings in networking and I have to say that a lot of the claims aren't nearly as outrageous as they initially sound. In one particular analysis, I calculated that saving 6W of power per blade in a fully populated 49U rack (the tallest rack that APC makes) across a 10,000 sq. ft. datacenter full of 7Ux16 blade servers in San Francisco saved $750k/yr in power and cooling costs assuming 35% rack density. Granted, it's unlikely a 10,000 sq. ft. datacenter is only going to house blade servers and nothing else, but given that the typical rack can consume upwards of 20-30kW, the fact that shredding 672W per rack (2.24% of a 30kW rack) can generate such a significant savings surprised even me.

Now consider that most datacenters are 20-30k sq. ft. and many new datacenters are 100k sq. ft. and you can start getting a sense of what kind of impact a mere 5% power savings can have on the bottom line.

Sunday, July 01, 2007

Book Report Catchup

While I haven't posted a book report in a while, I've still been reading. Chalk it up to other work keeping me busy... :-) So here goes an abbreviated report of a few books I've finished as of late...

The Nine Nations of North America by Joel Garreau

Here's an oldie (1980) that I heard recommended numerous times over a few years so I thought I'd give it a shake. Joel's attempted premise is that North America is really broken up into nine small nations, each with its own -isms and a clear divide between them. These clear divisions define their culture, economy, and local government in very distinct ways.

Okay, interesting premise. However, Joel then proceeds to ramble for a few hundred pages using isolated anecdotes to prove his point. Cute, but lacking any kind of analysis it's really a travelogue. Nothing wrong with doing a travelogue, but if I wanted a travelogue I would have explicitly gone and found one. After about 2/3rds of the book, I stopped and let it go.

To Joel's credit, his division of North America is (in my opinion) an accurate observation and one worth exploring. Even 25 years later, I believe that the divisions are still there and the lines would not be adjusted.

Alan Turing: The Enigma by Andrew Hodges

This is technically a preliminary book report since I'm only about 3/4ths done, however given that I've been slogging through this book for about two years now I figured it was time to make some mention of it.

Andrew Hodges writes an extremely detailed biography of the late, great, Alan Turing. For those of you not familiar with Alan, he is considered the true father of the modern programmable computer. (Wikipedia: Alan Turing) His mathematical insight was revolutionary at the time and led to extraordinary work by the likes of John von Neumann. Alan was also the key to breaking the Enigma which became the crucial turning point for the Allies in World War II. Countless lives were saved by this single breakthrough.

I haven't gotten to the point where Alan being gay creates the social pressure leading to him taking his own life. As interesting as his life should be, Andrew Hodges' writing style has a density that makes it a much more tiresome read than I expected. As a result, I'm left to picking up the book every once in a while only to put it back down after 20-30 pages. I hope to actually finish the book by 2010.

Made to Stick: Why Some Ideas Survive and Others Die by Chip and Dan Heath

I skim through a lot of marketing/business books. The reason is that most of them suck. I mean, really, truly, suck. Unless I'm pressured into reading something because it's "the latest thing" and I want to understand it better, I generally skip most books that come my way. Made to Stick not only passed the "this doesn't suck test", it's something that I recommend for everyone to read.

The book's premise is that making a message stick is formulaic. In reviewing countless sticky stores from urban legands to advertising programs to successful teachers, they bring their message down to six elements: Simplicity, Unexpectedness, Concreteness, Credibility, Emotions, and Stories. What makes the book itself sticky is that the authors don't make themselves out to be creative geniuses. In fact, the point out in numerous cases that it's the lack of creativity that often makes for the most sticky material. They go on to highlight an impressive number of well recognizable stories and advertising campaigns and reverse engineer them to see what made them work and categorize their elements.

The authors themselves apply their formula to the choice of stories they use for making their point. This of course makes their own stories and results equally sticky. In dissecting approaches I've used in the past, I can see where my better wins fell into these categories whereas others either missed the point, were too complex, or lacked a crucial element. At the same time, I'm working on applying the techniques to my own work and have seen pieces where it works. It's not a perfect game yet, but I've walked away feeling much more focused about my approach as a result.

All said and done, a big thumbs up. Highly recommended.

The Visual Display of Quantitative Information by Edward Tufte

Over the last few years, I've become increasingly aware of how information is presented in addition to the information itself. A recent project where I started aggregating a lot of market data into a single powerpoint for reference was especially eye opening in terms of how some charts and graphs shout out exactly what they wanted to show and others left me puzzled. At the same time, I started following the Visual Complexity and Information Aesthetics blogs both of which really highlighted how powerful charts can be. A quick search around and The Visual Display of Quantitative Information was clearly the grand daddy of The Books to get.

This book rocks.

Published in 1983 before the age of PowerPoint fiascos but after the introduction of computer graphics, Tufte manages to assemble a timeless book that not only shows what excellent charts should look like, but also what horrible ones do look like. He especially takes to task "graphical truth" in publishing with an especially evil eye towards magazines and newspapers that create misleading charts to sway public opinion. Some charts leave him sufficiently annoyed that he even prints corrected versions which would have a drastic impact on how the story is interpreted by the casual reader.

Ironically, there is much to learn for how to create manipulative graphics as there is in how to create clear, correct graphics with significant depth. Tufte of course wasn't trying to show how to be evil, but enough years in marketing and everything gets put through that jaundiced lens.

Edward has numerous other books as well, including an updated second edition. I of course plan to look into a few of those. He strikes a good balance between prose, examples, and making his point.

For anyone that needs to create graphs, this is the grand daddy of charting books and should be required reading.

Last but not least...

McGraw-Hill/Osborne asked me to write the fifth edition of Linux Administration: A Beginners Guide. Unfortunately, I'm no longer the right guy to be writing this book. While I can still do many of the day to day tasks of a Unix administrator, I've become too distant from the day to day experience to be a lead author on something like this. Wale Soyinka, my co-author in the fourth edition has agreed to write the whole thing for which I'm grateful. The book is still close to my heart and giving it up was a tough choice. However, I trust Wale to do an excellent job and maintain the quality. Look for the first printing sometime in early/mid 2008.