I’ve worked on a lot of systems over the past 11 years.  I heard the same discussions.  I heard the same arguments.  I’ve heard the same excuses.

One the issues that always seems to be in contention is how much a web application should log about user activity.  My stand has always been “Log everything you can about what is going on.  The only reason you should cut back is due to storage limitation.”  For some reason, this always causes arguments with my fellow developers.  (It ranks up there with the statement “Our app should be cross-browser compatible.”)

One of my big problems with applications written by junior (and some senior) developers is that they don’t log enough.  On a development machine or server, logging is not really needed—you can set a break point or log onto a server to see what’s going on.  In a production environment with tight change controls, this is not possible.

I’ve looked after third-party software applications in large companies which would routinely fail.  The company would spend a fortune for a software package from a small start-up no one has heard of.  We get this software, install it on our servers and before long, we have our first exception.  Angry users call me.  I call the vendor:

“We are getting an error number x00012012928 when click on the save button.”

“Hmm. What happens when you click on the popup?”, he asks.

“The application crashes.  Now no one can log in.”

“Can you check to see if the server is still up?”, they ask.  This is when I glean that he doesn’t really know what’s going on.  He’ll ask for a reboot next.

“The server is up.  I can still get to the web pages. But no one can save anything.  Can I talk to the developer.”

“I am the developer” the snooty developer replies.

“Okay.  So why is it doing this?”

“Oh.  Umm. . . .  It shouldn’t happen.”  Yeah.  No sh*t.

“What is x00012012928?" I ask trying to move things along.  “It looks like an internally generated error number.  A description of the error would have been nice.  I’ve checked event viewer but see nothing.  It looks like the exception is being caught, but not handled.  What would generate this number?”

“It could be a number of things . . . “  This is the wrong answer.  If you are going to raise your own errors, be as specific as possible.  You can’t anticipate every error, but you can differentiate between db or web error for example.   This conversation goes on and on where eventually I need to get someone with server admin rights to send him an IIS log so he can review it for a few days.  Meanwhile, I have to try to calm down an angry user base and continue to chase the vendor.

I’ve been in the above situation at least a half-dozen times in different companies.  It most definitely is not an exaggeration.

I like to contrast this with a friend of mine who wrote an application where he logged everything.  He kept log files as text files in a web root where he could access them securely with .htaccess rights.  Every day, a new file was generated and files over 30 days old were deleted. 

One day, he got a call from an irate user.

“I’m trying to use this rubbish application and it isn’t working.” angry user yells.

“I see. What is your username?” the developer calmly asks.

“John_Smith”

“I see you logged into the application 3 times today.  Did you get an error every time or just the last time.”  Already the developer with logged activity at his disposal knows more about the user’s problem than the user knows.  If there was an exception, he would have been able to see it in his logs.  If there is no exception listed, he can view user activity.  “I see the last page you accessed was the transaction details page.  Is this where you get the error?  Can you describe it?”

“The button does not show up to save the data I entered,” the calmer user explains.

“I see.  This is a common problem.  You left a mandatory field out.  You should see it highlighted in red.”

“Oh yes.  I see it now.  How did I miss that?  Thanks.”

So the developer had 3 things working for him:

1.  He had more information at his disposal than the user had.  He could identify an exception or user error.

2.  He did not try to make the user feel at fault when he clearly was.  (“This is a common problem” may necessarily be true, but there is no better way to put someone on the defensive than to accuse them of being wrong)

3.  He spoke in a calm, unassuming, and sympathetic voice.  A user can quickly tell whether you are doing everything you can to help him or if he has to try to prove to you that his problem is real.

So, I’m always in favour of extreme logging.  I hear the same excuses every time why this can’t be done.  “It will take up too much space.”  “It will be too difficult to clear down.” “Nothing should go wrong with the application, because we tested it.” “We will log the exceptions.  That’s all we need.”

In London you see a lot of guys with fold-up bikes.  They’re pretty cool.  Kind of like laptops for bikes I guess.  You can take them anywhere.

But nearly every guy I see with the folding bike is decked out in full cycling gear.  I don’t just mean the helmet (everyone should wear one).  I mean biking shirt, spandex trousers, shoes, etc.  They are obviously on their way to work and they are being healthy.  I have no problem with that.  But if you are going to ride a half a bike, shouldn’t you wear just the basics in clothing?

Before I bought my motorbike, I was looking to buy a scooter instead.  They look small and fun and easy to zip around in.  I’ve rented them in Hawaii and it was really nice to cruise around with the wind in my hair.  But helmets weren’t required there.  It was half a motorcycle, so it didn’t require a full motorcycle safety commitment.  In England there is a helmet law. When I saw that I would have to wear the full garb with a scooter that I would on a bike, I decided to get the full bike.  (I’m really glad I did, by the way.)  I guess I kind of think of fold-up bikes as the pedal equivalent of scooters.  I’ve never ridden one, so I’m in no way an authority.

I guess I’m guilty with this over-dressing when it comes to running.  Back in my early twenties, when I had little money, I can remember looking at special running shirts which removed sweat from your body and dedicated running shorts which fit the contours of your legs and marvelling at how expensive they were.  There was nothing wrong with my ratty-ass cotton t-shirts and shorts.  This high-tech gear didn’t help that much—the important thing was to get out on the road.  I used to snicker at people who wore that stuff and obviously didn’t run very often.  Now, I have a few running shirts and a couple pairs of those shorts.  I head out in the morning looking like an Olympic athlete in training – except for the belly of of course.  I don’t know how much the gear helps me.  It’s more for motivation than anything else.  Sometimes, that one thing that gets me out on the road is the chance to test out my new shorts or see how comfortable my new running shirt is.

Maybe that’s why the portable bikers wear it.  Because it was fun to shop for and it keeps them on their bikes.

I’ve mentioned this on a previous post but I’ll take some time to elaborate a bit here.

Every train commuter wants to sit with a vacant seat next to him.  Sometimes, that’s not possible.  So the next best thing is to sit next to someone who is sleeping.

Frequently, I get on a train and see loads of seats, but all of them next to someone.  If there is one seat available only, it’s a no-brainer—take it.  But when there are loads of seats, you got to choose.  Everyone watches you to see where you are going to sit.  No one wants you to take their prized vacant seat.  They try to use tricks like sitting in the aisle seat because you probably wouldn’t bother asking them to move so you can squeeze in there.  Other people put their bags on the vacant seat.

Here are some things to look for:

1.  Never sit next to the guy reading the paper.  He will be elbowing you every few minutes as he turns pages.  He’s probably snooty anyway.  When they announce a delay because of a signal failure, he’s the guy who will huff and puff the most.

2.  Avoid sitting next to someone in their early twenties.  They may not be on the phone now, but it’s coming out within the next 5-10 minutes.  I know very few people I can call at 7am on a weekday.  People in their twenties know loads.

3.  Avoid sitting next to a non-commuter.  They may try to strike a conversation with you.   You just want to listen to your iPod and get to work.

4.  Find a sleeping guy (there’s always at least one).  Sit next to him.

The sleeping guy is great.  He doesn’t care what’s going on.  He will occasional jolt up and look around to see what station we are stopping at, but then he will calm down and drift back off.

The sleeping guy doesn’t care what you are doing on your laptop.  As I type this, the guy next to me can care less.  There’s nothing worse than see the person sitting next to you watch what you are typing as you type it.

The sleeping guys doesn’t care that you sat next to him.  He doesn’t roll his eyes or huff as he moves his bag off your seat.  If you are careful, he may not even know you sat next to him at all.

Occasionally, you get a guy who snores.  This isn’t so bad.  People will look over at you and you try to sit up straight and alert so everyone knows it’s not you.  You can sometimes look back at them and sort nod your head sideways at the sleeping guy as if to say “it’s him” and they raise your shoulders as if to say “what can you do?”  No one expects you to wake the guy (unless that’s why they are looking at me).  I respect the sleeping guy too much to wake him.

So, that’s it.  My one and only commuter tip.  May it make your commutes as enjoyable as it makes mine.