New Server – New Fun!

This is the amazing “new” server that this blog is hosted on. Using a dynamic DNS service and Ubuntu on a 9 year-old MacBook, I have taken control of my blog again, trying to revive it from the untouched archive it has been for the last few years.

[Oh, and if you have arrived here from a Newest Industry link, don’t panic. Just search for the article you want – they’re all here.]

I’ve just recently changed companies (through an acquisition), so I will have new web performance items to hook into as I get a chance to work with new customers.

All raise your glass – PerformanceZen is back.

The Rule of Thirds: The Web Performance Analyst

Blurry Man - Brian Auer - http://www.flickr.com/photos/brianauer/2929494868/Recently, there has been a big push for the Dev/Ops culture, an integrated blending of development and operations who work closely together to ensure that poor performing web and mobile applications don’t make it out the door. They have become the rockstars of the conference circuit and the employment boards.

I fit into neither of these categories. I have never run anything more than a couple of linux servers with Apache and MySQL. I write code because I’m curious, not because I’m good at it – in fact, I write the worst code in the world and I am willing to prove it!

I am a member of a web and mobile performance culture that is language and platform independent, to use some buzzwords.

I am a web and mobile performance consultant and analyst.

I can take apart reams of data to find statistical patterns and anomalies. I believe that averages are evil, and have believed this for more than a decade. I have been using frequency and percentile distributions for almost as long and watched as the industry finally caught up.

I can link the business issue that faces your company with the technical concerns you are facing and help guide you to the middle ground where performance and the balance sheet are in careful equilibrium.

I don’t care what you write your code in. I don’t care what you run it on. Now, don’t get me wrong: I respect and admire the Dev/Ops folks I have met and know. I am just not in their tribe.

9/11 – Where were you?

On that Tuesday morning, I was in the air, on a flight from San Francisco to Denver, the first leg of a trip to Boston on business. I was excited – it was a client I had been looking forward to working with, and it seemed like an exciting opportunity. The flight was mostly empty and I had the luxury of a Bulkhead seat on a 777 – the middle section of my row was my kingdom to command, at least until Denver.

I don’t know where we were (probably near Tahoe) when the plane made a hard and very sudden turn away from the direction we should have been traveling in. All the passengers on this mostly empty flight (remember those flights?) seemed to get a quizzical look on there faces. This turned to concerned looks on our faces when the pilot came on the intercom to announce that the flight had been diverted to Sacramento in response to a “National Security request”.

Through the remainder of the short flight to Sacramento, it was clear that the flight attendants were visibly shaken (it was a United flight) and were having a hard time holding it together. Professional to a fault, they graciously brought me an extra yogurt when I asked. I had no clue.

The landing in Sacramento, an airport that was just barely long enough to accept a 777, is one that I remember to this day. As soon as the wheel touched the tarmac, the brakes screamed and reverse thrusters howled, the pilots trying to bring a “heavy” plane to a stop on a runway that was nominally rated for the beast they were bringing in.

We were still unsure what had happened, but the few of us who had the limited Web available on our phones were reading very conflicting and inaccurate news items. The flight attendants asked us to put them away, but for once they were doing it for optics, knowing full well we wanted to know what was going on as much as they did.

Outside the windows, planes of all stripes and sizes, from airlines I had never heard of or only seen in the air on approach to SFO. And clearly, there were two problems.

  1. There were no gates for us to pull up to.
  2. When we pulled to stop, the ground crew looked at us with dazed looks, going “How the hell do we offload a 777?”

We finally staggered off the plane, via a 60s style airplane ladder. By this time, the flight attendants were crying and holding each other. It wasn’t until later that I realized that they had all lost friends on the planes.

After this process, the few of us streamed into the Sacramento terminal, headed for the baggage carousels. It was then that we saw the first tvs.

The line of passengers briefly stopped in shock. A few of them peeled off to the bar, where it was clear that the drinks were on the owner. The rest of us grabbed our bags and shuffled out of the terminal.

I called my wife and got through to our house on the second or third try. My mother-in-law, who was visiting, picked up the phone. I said I was alright, and asked to speak to my wife. SJE picked up and I told her I was on the ground in Sacramento and I was alright.

She was clearly confused and asked why I was calling. Our youngest was only a few months old, and sleep was at a bit of a premium. I knew she would have had no clue, and told her to go turn on the tv. Five minutes later, she called back and, in a clear but very stressed voice, told me that she was going to come and get me.

By that time, I told her that it was completely unnecessary. By an act of organization that has amazed me and endeared me to United until this day, they had arranged for a bus to come to the Sacramento terminal and take us back to SFO.

The bus ride was surreal. Completely quiet, except CNN radio. No one spoke. No one spoke on cell phones. We were all processing what we thought had happened, as CNN Radio tried to do the same.

The bus arrived back at SFO, making us some of the few who at least got back to where we had started our day. We gathered our bags, and shuffled off to wherever we were going to go. In an eerie silence.

Coming down the stairs from the top level of the airport, I saw the pandemonium at the ticketing counters as thousands of people desperately sought a way to get somewhere – home, away, flee. I was lucky. I got to go down to the arrivals area and wait.

I was picked up by SJE about 20 minutes after I got off the bus. As we headed home, south on 101, we watched a lonely aircraft descend out of the crystal blue (ok, it’s the Bay Area – gray brown) sky. It was clearly one of the final flights to land at SFO that day. The 747, a plane from one of the major Asian national carriers was a glorious sight as it approached. But then we noticed the frightening parentheses that summed up the day – this glorious feat of engineering was bringing its passengers in accompanied by two F-16s.

We heard the roar of the fighters peeling off as the 747 put its wheels down behind us. And, as we drove, the great silence began.

The Joy of the Platform

In the last few months, I have found myself uttering the word platform on an almost daily basis. As I was flying home last night, I began to consider what that actually means.

In the world I work in, customers bought a product or a tool. The purchase is driven by a desire to solve a problem or prevent a problem from appearing in the first place. It was a point solution, a single point of entry into an organization and added a very limited amount of value to a siloed compartment of an organization for a limited period of time, before the next shiny toy came along that purported to do the same thing, only better.

Economies of scale be damned, full inefficiencies ahead!

Companies that sell platforms, or have begun to to consider doing more than just paying lip-service to the word, look at the world with a different filter. The customer is seen as a holistic entity, as complex as any patient who comes to a doctor for treatment. If two people come to a doctor with the flu, they don’t always get the same treatment, as the one patient may be sent home for rest and the other rushed to hospital because their compromised immune system means the flu will kill them without specialist care.

The best platforms are those that are focused on one to three key aspects of customers business or way of doing business and provide a unified way to perform these 1-3 functions. The customer should not be forced to go to completely different places to use each tool on the platform.

Platforms have unified flows, and customers can expect that using different parts of the platform will be easy to learn, as they all work the same way. An example of a bad platform is Microsoft Office. When you go to the File Menu in a Microsoft Office product, you know that regardless which product in the suite you are using, the same items will be there. Where Microsoft Office fails as a platform is in the way that the rest of the menus and actions are not unified, with Powerpoint behaving differently from Word, which are both different from Excel. Microsoft Office is a the case study of history is getting in the way of ease of use, of standalone products loosely linked, like cheap knock-offs of Lego™.

Platforms are truly extensible. If a customer needs an additional component of the platform, it can be enabled (after the appropriate business negotiations) in minutes.

Platforms need to allow simplicity when needed and complexity where required. While a 10-person company and a 10,000-person company have different needs, the same platform should be able to support these needs. Salesforce.com is a classic example of this – in their world, they don’t care what the size of your company is.

And, platforms have to guided by product management teams, to have a shared vision. Product management has to enforce a strong adherence to the core values of focus, unity, extensibility, and complex simple complexity. A product management team that lacks the leadership to drive these values will produce a broken platform

How does your platform compare against this checklist?

Effective Web Performance: The Wrong 80 Percent

Steve Souders is the current king of Web performance gurus. His mantra, which is sound and can be borne out by empirical evidence, is that 80% of performance issues occur between the Web server and the Web browser. He offers a fantastically detailed methodology for approaching these issues.

But fixing the 80% of performance issues that occur on the front-end of a Web site doesn’t fix the 80% of the problems that occur in the company that created the Web site.

Huh? Well, as Inigo Montoya would say, let me explain.

The front-end of a Web site is the final product of a process, (hopefully) shaped by a vision, developed by a company delivering a service or product. It’s the process, that 80% of Web site development that is not Web site development, that let a Web site with high response times and poor user experience get out the door in the first place.

Shouldn’t the main concern of any organization be to understand why the process for creating, managing, and measuring Web sites is such that after expending substantial effort and treasure to create a Web site, it has to be fixed because of performance issues detected only after the process is complete?

Souders’ 80% will fix the immediate problem, and the Web site will end up being measurably faster in a short period of time. The caveat to the technical fix is that unless you can step back and determine how a Web site that needed to be fixed was released in the first place, there is a strong likelihood that the old habits will appear again.

Yahoo! and Google are organizations that are fanatically focused on performance. So, in some respects, it’s understandable how someone (like Steve Souders) who comes out of a performance culture can see all issues as technical issues. I started out in a technical environment, and when I locked myself in that silo, every Web performance issue had a technical solution.

I’ve talked about culture and web performance before, but the message bears repeating. A web performance problem can be fixed with a technical solution. But patching the hole in the dike doesn’t stop you from eventually having to look at why the dike got a hole in the first place.

Solving performance Web problems starts with not tolerating them in the first place. Focusing on solving the technical 80% of Web performance leaves the other 80% of the problem, the culture and processes that originally created the performance issues, untouched.