Rental Car IT

I travel a lot. Mostly, when I travel and need a car, I get one through one of the major vendor's premiere customer program, meaning that I get to walk right to the car and drive away without much formality. Which is a good thing, because every once in a while, something is amiss and I have to go to the counter. And that entails dealing with rental car IT.

The amount of information you need to rent a car seems pretty small. Even if it's not, it's very well defined. You'd think that they would have the process honed; it is, after all, the primary thrust of their business. But watching the sheer number of keystrokes that the counter attendee must perform to put me in a car is astounding. The same is true when you bring it back. It's like they are typing the great American novel. What could possibly require so typing? They know who I am. They have all my credit card, insurance, and driver's license information (enough that they'll usually just let me get in a car and drive away). This isn't confined to a single rental car company either. I've dealt with a bunch of them and they all have an enormous amount of data entry.

Unlike a lot of problem domains in which I've specifically worked, I don't know for sure what's going on for rental car companies. But here's what I suspect: their IT infrastructure is strangling them. Ironically, many of the companies that embraced IT very early on (i.e., in the mainframe era) are suffering a lot now. Much of the interest in SOA derives from the desire to get out of the deadly embrace of fossilized, astoundingly brittle IT infrastructure.

Closer to home, I've recently been doing some consulting at a large company, helping them define their evolution towards a better tomorrow. I was talking to one of their senior IT staff, and I mentioned that it seems like they don't have a really good idea what their users need software for, and that maybe we should go talk to them. He looked at me like I had a new eye sprouting on my forehead, and said to me "We've tried talking to them -- they don't know what they want, so we have to define it for them. You can't be so naive to think that we can actually talk to the users." At this large enterprise, software is its own ecosystem. The users of the software almost never come up in meetings. Instead, it's a gigantic plumbing exercise. What's ironic is that this particular company is primarily run on information. Yet, they are so far down the rabbit hole of plumbing and complexity, they have managed to create mountains of rubbish. They are in the deadly embrace of accidental complexity, not essential complexity. My coworker and I identified their IT needs for the entire enterprise as small to medium, if this were a green field. But, of course, they have information trapped in mainframes, in several different formats of databases, in packaged applications, and scattered hither and fro, like lots of enterprises.

By way of trying to get them to rethink some of their decisions, we tried (and were marginally successful) in getting them to define some core principles, like simplicity and flexibility. What was funny about that exercise were the looks we got from the no nonsense King of IT: "Of course, we want things to be simple and flexible -- why are you bothering to tell us this?" Yet, in the next sentence, they are talking about spending 3 million dollars on a packaged application to help them with one small part of their business, rather than building it themselves (which we all thought would be cheaper but take longer). That's $3,000,000. But, of course, the packaged application talks directly to their databases, meaning that we can no longer freely make changes to the database without breaking the package, meaning that we can't evolve the database, meaning that we've lost both simplicity and flexibility. Over and over, they complain when we talk about rethinking their priorities, then turn around and make the same decisions that got them where they are now. Frustrating!

At another company I did consulting for years ago, they had a special mainframe application that handled one part of their business. I don't know how much it cost, but it had to be a lot because their vendor came to them one day and said "Look, we really just can't take any more money -- we're bloated and frankly we can't figure out how to spend all you've given us already." Instead of taking this opportunity to rethink how this part of their business works, the found another mainframe application that did the same basic thing, and spent 43 million dollars changing around the life support for this thing. Fundamentally, the problem they were solving wasn't that tough. I know; we were working on a piece of it and got a good feel for the whole thing. They were so drowning in the accidental complexity of the way they had always done it that they couldn't see the actual problem anymore. I walked into a conference room at one point, and saw a diagram that literally covered the entire wall with boxes, lines, and 8-point font describing the enterprise architecture (no, sorry, Enterprise Architecture). When one of the client developers walked in, I said "Wow, it's a good thing you guys dismantling this mess" to which he replied "No, that's the new one we're going towards". Decisions like this mean I have to spend my time in long lines in places like rental car counters.

Going back to first principles is hard, and many companies think it's too late. I've been involved on projects where getting back to a simple solution takes years. But it's worth doing. Otherwise, the company will drown in self-inflicted complexity, when IT becomes a governor on the business rather than a strategic advantage. When that happens, some other company with nimble IT will eat their lunch. Software can be either an asset or a liability.

Missing Family Member John Glasgow

My wife Candy's cousin John Glasgow is missing. John was last seen leaving his Little Rock, AR home Monday morning around 5:30 am, January 28, 2008. A cell phone ping later that day indicated that he was in the vicinity of Petit Jean Mountain. His car was found unlocked the next day at the Mather lodge on Petit Jean with valuables still inside. He is believed to have been wearing a green Marmot down jacket and khaki pants at the time of his disappearance.

His family and friends are asking for help in locating John. We are hoping that someone out there will see John's picture and read his story and come forward with information that can help us find him. Distressingly, official search efforts were called off 2 weeks ago on Friday, even though the family has mounted their own search. Please go to www.findjohnglasgow.com to see a picture of John and print off a flyer. If you could put it in your car window or some other visible place, it would help us a lot. It is possible that he could have traveled out of the area where he went missing, so we are trying to get the word out on a national level, to cover all possible scenarios.

The Real JDK 2.0

I always wondered what in the world the Sun marketing guys were thinking. They kept changing the real name of the JDK. Starting with JDK 1.2, they decided that they wanted to call it "Java 2", and the "Java 2 Platform". But developers still downloaded JDK 1.2. OK, that makes some sense, I guess. Then, when JDK 1.3 came out, it was still "Java 2 Platform". If there was any logic, it would now be the "Java 3 Platform". Well, OK, so now it's Java 2 forever. Then, when JDK 1.5 appeared, it became Java 5. Now they are clearly just making this stuff as they go. Now, the current thinking is that it's just the "Java Platform", and "Java Enterprise Edition" (to avoid the charming "JPEE" acronym). What in the world is going to have to happen for the real version number to trip up to 2.0. And why the reluctance? Is there something magical about version 2.0? Why didn't the marketing and technical guys just get together when JDK 1.2 came out and call it "Java 2" then? It's not like they're going to run out of numbers -- there are literally an infinite number of them!

Without realizing it, the technical guys didn't think (and apparently still don't) that Java was good enough for a real Version 2. They've been waiting...and now it's here. Groovy is the REAL Java 2. Henceforth, we can think of the Java language (not the platform) as forever 1.x. Groovy is what the real second version of Java should have been. The technical guys must have felt it their guts all along.

I've heard some rumors about wacky version numbers for Groovy. It leapt from 1.1 to 1.5. Stop it! When you make changes to it, increment the bloody first number! Unless you want someone in a decade writing a smarmy piece about how your technical marvel just got supplanted, and that it was a version 1.x technology all along.

aboutGroovy Podcast for 2G

The 2G-Groovy/Grails Experience is just around the corner, and my buddy Scott Davis asked me to chat a bit about the talks I'm doing there ("Design Patterns" in Groovy, Groovyizing You Day Job, and Comparing JRuby and Groovy). That chat is now cast into pod, at this PodCast.