Karen Morton

Today I’ve added Karen Morton’s blog to my Blog list. I met her a few years back at a course I helped teach in Tennessee. She generously describes that the course changed her life, and she has since changed mine.

Recently, Karen helped me found Method R Corporation. She’s our director of education and consulting. Many of you have met Karen already in a classroom.

Karen is an excellent teacher (that means more than “excellent instructor”), and she’s just one of those rare people who, when she says she’ll do something, it’s as good as a COMMIT. She is also one of the best SQL optimizers I know, on top of being a pioneer and first-rate practitioner of the techniques Jeff and I talk about in Optimizing Oracle Performance.

She has already taught me many things, and I’m eager to watch what she will have to say online.

May 28 seminar, Minneapolis

Today I'm making preparations for another public event: this one is a one-day Performance Seminar I'll conduct in the Minneapolis area for Speak-Tech on May 28. In the morning, I'll do a "Why you can't see your real performance problems" session, and in the afternoon, I'll do "Measure once, cut twice (no, really)," which I discussed briefly here yesterday.

I'm looking forward to a lot of audience interaction on this one. We should have plenty of time on the 9:00am-4:30pm agenda for discussion.

Dilbert on "Measure Twice, Cut Once"

Speaking of "measure once, cut twice," here is a good Dilbert strip to get you in the mood:

Getting Ready for ODTUG

It's been too long since I've blogged. I've been busy doing all the little things you have to do when you start a business over the past few weeks. You know, web pages, contracts, business cards, email, insurance, health care, payroll, bills, furniture, vacuuming the floor, more contracts, and so on.

Today I received a timely message from Mike Riley of ODTUG asking the speakers at the event to please blog about our upcoming participation in ODTUG Kaleidoscope 2008 next month in New Orleans. Excellent idea. I like ODTUG a lot, because it's a rare event that I attend where a lot of software developers get together. These are the people who have the most leverage over software performance, which is my life's work.

On Wednesday, June 18, I'll be presenting a paper called "Measure once, cut twice (no, really)." I had to put the "no, really" in there to make people understand that it wasn't a typo. I presented this topic for the first time at the Hotsos Symposium in March, and I was reasonably happy with it, as first presentations of a topic go. Here's the abstract, in case you don't want to click away from here just now:

“Measure Twice, Cut Once” is a reminder that careful planning yields better gratification than going too quickly into operations that can’t be undone. Sometimes, however, it’s better to measure once, cut twice. It’s one of the secrets behind how carpenters hang square cabinets in not-so-square kitchens. And it’s one of the secrets behind how developers write applications that are easy to fix when they cause performance problems in production use. The key is to know which details you can plan for directly, and which details you simply can’t know and therefore have to defend yourself against. In this session Cary will discuss some aspects of software development where flexible design is more important than detailed planning, using woodworking analogies for inspiration. Cary will describe some particular flexibilities that your software needs, and he’ll describe how to create them.

It's essentially an exploration of why I think agile development methods work so well (for some personality types), with examples both from work and from the home wood shop.

I'll hope to see you there.

Messed-Up App of the Day

I hate to complain so much, but having spent my third 8- to 10-hour stretch using a really bad application this month, I'm compelled to say something. Today's Messed-Up App: the economy-class seat in an American Airlines Boeing 777 aircraft.

Alright, I get that in economy class, you're not going to get five feet of legroom, or 30-inch wide seats that lie flat or spin to face each other. That's okay. What I do get is transportation to Europe with a cash savings, relative to an upgraded fare, sufficient to purchase—if I wanted—this Rolex. And, actually, it's really nice how each seat in economy class has its own in-seat audio/video unit. You can watch whatever you want back there. Or nothing at all. That's very nice.

But the way someone designed the A/V remote control into the armrest is just wrong. Each remote snaps into a compartment designed into the top of the armrest. Here's what it looks like.

And so here's your decision tree: Either you'll rest your arms on the armrests, or you will not. Not much of a decision there. Even if you decide not to rest your arms on the armrest, you'll probably do it accidentally if you have the good fortune to fall asleep (which you better do, because you have to work tomorrow).

The remaining decision is influenced by the following observation: If you leave the A/V remote in its cradle, your arms inadvertently push buttons "TV On/Off" or "Channel Up/Down". Fortunately, the "Call Attendant" button is difficult to press accidentally. The other choice is to take the remote out of its cradle and put it in your lap so that you won't accidentally press the buttons while you're watching 30 Rock. The problem with taking the thing out of its cradle is that resting your arm on the resulting pointy-thinged-chasm becomes really uncomfortable by the time you've sat there for a while.

Oh, and you don't get to make a choice for your other armrest, which looks like this:

That's your neighbor's A/V remote.

...Whose buttons you're pushing accidentally with your other elbow, if you happen to be wider than your neighbor.

The only decent workaround I've found is to put your pillow underneath your arm on one side, and your blanket on the other. This brings other troublesome compromises into play, which I won't go into. One of them requires communicating with your neighbor.

The whole point, and what I believe makes this story relevant for software developers, even if you don't travel economy class to Europe very often, is this. People who design things need to actually use the things they design. If the person in charge of designing seats for American Airlines' Boeing 777 aircraft had been required to sit in a prototype of this particular seat for the 8-hour flight from DFW to LHR (or even better: the 10-hour ride back), this seat would never have made it into production.

People should test their designs by actually using them, under circumstances as similar as possible to the actual circumstances that the users of the design will endure.

Stop Guessing

Here are two new YouTube videos featuring Anjo Kolk and me. These were filmed at the Miracle SQL Server Open World event held April 3, 4, and 5 at Lalandia in Rødby, Denmark.

Mogens Nørgaard introduced these videos with the statement, "May I present the new Miracle TV concept called SlowTV.... where people don't have to stare into the lens while trying to remember what they were talking about, but can roam freely with their eyes, just like in real life."

• Stop Guessing - Anjo Kolk, Miracle Benelux
• Cary Millsap stopped guessing

Messed-Up App of the Day

Greetings from London Gatwick Airport. Messed-up app of the day: National Express self-service ticketing kiosk, London Heathrow Airport, Terminal 5.

I'm connecting through London on my way home. Unfortunately, my connection requires a bus ride from Heathrow (LHR) to Gatwick (LGW). Not my favorite, but I've done it before and survived. Bus is run by National Express. It's a £19 ticket; apparently only £17 if you're doing the BA/AA ugly connection thing I'm doing. I don't remember having to pay that myself before, but today I'm glad I did.

One way to buy your ticket is through one of the self-service ticket machines outside baggage claim. Here's approximately how that went:

Machine: Where will you be going?

Me: London Gatwick.

Then the machine I was doing business with popped a widget that showed the number of qualifying journeys the machine had found so far. It's one of those "watch the number change really fast" fields. I watched it count through 10, and then 50, and then 100 (jaw drop), and then eventually 500, until finally, about a minute later, the counter reached roughly 2,000. Finally, it said, "2,000 qualifying journeys found", or something to that effect.

Then it showed me the first half dozen or so of those "qualifying journeys."

• 11:10 Heathrow to Gatwick
• 11:20 Heathrow to Gatwick
• 11:30 Heathrow to Gatwick
• ...

It was 10:55 at the time. I chose 11:10.

"Brilliant."

Let me summarize. This thing computes the schedule for each of the next 2,000 bus rides you might want to take. You only look at six of them. The cost to you for all this information you don't look at is (N+1)*60 seconds of your time, where N is the number of people ahead of you in the queue for this machine. If there are six or more people ahead of you in your queue, then you're probably going to miss the next bus.

I don't know whether it's an Oracle application behind this or not. It doesn't matter. It's stupid either way.

There's a simple solution. Begin by asking approximately when the user wants his bus ride. The default value should be "now." I don't know what percentage of people would ever want to change that value, but I doubt I ever would. Then instead of returning 2,000 qualifying journeys sorted by departure time, return only journeys whose departure time is within ±1 hour of his choice. Of course, list only those departure times that occur in the future.

SQL like this would do it:

select   departure_time, origin, destination, ...
from     whatever1, whatever2, ...
where    origin = :here
       and destination = :there
       and departure_time between :your_time - 1/24 and :your_time + 1/24
       and departure_time > sysdate
order by 1

Okay, that's functionally dirty because what happens if someone specifies a :your_time value of 3am, and there are no buses scheduled anywhere within 2am-4am?

Then be clever and use analytic functions to find the 10 rows that have departure_time that are closest to :your_time. Be a developer.

The functional difference we're trying to achieve is to stop burning computing and communication resources producing 1,990 rows that nobody wants to see anyway. The benefit? Reduction of human suffering in situations wherein frustrated people who are trying to make their connections are missing buses because a machine that takes their money is spending time making calculations nobody needs.