« August 2004 | Main | October 2004 »

September 29, 2004

Dell Technical Support: Fact or Fantasy?

Ask around and you're bound to hear a few horror stories about people having to deal with the good people at the other end of the Dell technical support phone lines.

My company now uses Dell as it's sole laptop supplier. Occasionally, we do need to venture into this lion's den. Generally, this is not a task we look forward to with great enthusiasm, but one which must be done nonetheless.

I've recently had to go through this process as my laptop has been on the fritz of late. In short, it had taken to completely freezing at random intervals with no prior warning, forcing a hard reboot - and usually a cooling off period in between before returning to normal operation. Average frequency of these crashes was once a week, although I would occasionally get a bad day where it would crash 3-4 times in rapid succession.

I first experienced this problem when I started on my current project and began using the laptop as a linux development machine in earnest, prior to which it had been an occasionally-used Windows box. My natural inclination when these problems first occurred was a problem with Fedora Core 2, which I'd installed for the project. After 3 re-installations of the OS (both FC1 and FC2) with no change in the symptoms, I realized it wasn't a software issue. These findings were also in keeping with my general belief that Unix OSs don't behave that way. Adding further weight to my conviction was a crash occuring on one of the brief occasions where I'd rebooted to Windows XP for some reason...

"Bugger!", I thought, "Looks like a hardware problem - time to speak to Dell" :-(

(Mentally, I was leaning toward a dodgy motherboard, as I've run diagnostics previously on the hard drive and RAM with nothing untoward reported.)

The problem with dealing with help desks in general is that they are usually ill-equipped to deal with problem domains beyond the ordinary. When it comes to PCs, "the ordinary" almost always refers to running some flavour of Windows. The realization that I would have to explain I was running "not Windows" almost 100% of the time chilled me to the bone. From a diagnosis perspective, this problem was tricky in that I had no way of reproducing it and the frequency was non-deterministic enough that I couldn't even guarantee when it would next occur.

Sure enough, my first phone call was an uphill battle through molasses. After explaining the issue to my Dell consultant (hereafter known as C1) she attempted to get me to run hard drive diagnostics whilst the laptop was booting. After 4-5 attempts, I was completely unsuccessful. As it turned out later, the key combination she was instructing me to use was for an entirely different series of laptops. Bear in mind this is a Dell employee who didn't have the correct information of the diagnostic key combination for their own hardware!

Less disturbing but more amusing for my collegues who were witness to half my phone conversation were C1's attempts to follow the usual problem resolution flowchart in a later part of the conversation. Obviously targeting the "ordinary" segment of the market, some of the suggestions offered to me were:

  1. "It could very well be a virus! Do you have up-to-date virus protection software installed?". Bzzzzt, not in Linux land baby! There was a slim chance that I was the first ever victim of the first ever nasty Linux-based virus, but I doubted it. And it doesn't explain the Windows crash I'd seen, although I'm not naive enough to believe it could have been caused by one of the 100+ things that cause Windows to behave erratically on a regular basis.

  2. "Have you tried clearing out your Internet Explorer browser file cache?" Hmmm, so you think the problem affecting me whilst using FC2 is caused by something dodgy living on a different file system on a different partition on a different OS that I'm not running!

However, there is a sliver lining to this dark cloud...

Later that day, I had to call Dell back again and ended up speaking to a different consultant (C2). This one had a much better grasp of the problem solving process and didn't press the Windows issue once he realized it wasn't a factor. He also understood that the nature of the problem was slippery enough that the underlying cause might lay in several areas. Therefore, he dispatched a service person with a new motherboard, RAM stick, CPU, CPU fan and hard drive, hoping this sledgehammer would crack my nut of a problem. Now, we were getting somewhere!

Once the service guy arrived (he left it late in the day as I'd requested, so my downtime during work hours was limited), I even managed to convince him to postpone the hard drive replacement for a later visit (if needed) as a new hard drive would require a full working day of software re-installation and configuration, a task I would prefer to avoid if possible.

And, fingers crossed, I think my laptop is now OK. It's been 12 days and counting since it's new motherboard, memory, CPU and fan were fitted and no signs of freezing as yet. Woot!

So, my overall impression of Dell's technical support services were: generally favourable. C2 was very customer-focussed and bright enough to realize the slightly unique nature of my environment and problem. His attitude overcame the nasty taste C1 had left me with. The logistics of the service do present their own problems - offshoring to a country where English is a second language can present communication issues, which are be exasperating when dealing with inflexible problem resolution processes and inflexible people following them.

But, as with most things, it's the human element which makes or breaks the impression. I don't believe Dell technical support is inherently evil, however given the number of horror stories I've heard or witnessed (e.g., a consultant asking which software application caused the key to physically drop off the keyboard!) suggests there are far too many Dell technical support personnel operating along the lines of C1 and far too few like C2.

p.s. C2 will definitely be getting a nice feedback email from me once 2 weeks have expired and I'm convinced the problem has been resolved.

Posted by Andy Marks at 11:32 AM | Comments (1)

September 24, 2004

ServletTestHelper - you're my hero!

Largely as a result of a coincidence, my project has had a couple of bugs reported recently which have been caused by people placing redirection logic in servlets without using a return statement after the response.sendRedirect(...) call. Remembering to include the return can be a tricky thing to do: conceptually a redirect changes the flow of control within the application, but from a Java perspective, any code after the redirect call in the method will still be executed, just like in any other method call. Depending on what this subsequent code does, the symptoms of this problem can be somewhat difficult to diagnose.

Mock object testing to the rescue!

Also concidentally, I've been using the Mock Object ServletTestHelper for the first time in anger today, and discovered a rather pleasant side-effect of this mechanism for servlet testing. If you forget to include a return statement and another two redirect calls happen to be executed within the same test, you get an error a along the lines of:


junit.framework.AssertionFailedError: MockHttpServletResponse.sendRedirect had different sizes
Expected Size:1
Received size: 2 ...

Better still, this exception is thrown not from an explicit call to verify() or a redirect-specific assertion, but from the central testDoPost() method, so you don't even need to add extra checks to your tests to ensure this rule is followed. You get it for free!

Posted by Andy Marks at 12:33 PM | Comments (0)

September 16, 2004

Preaching to the Inconvertible?

My collegue Patrick and I have been pacing each other reading Peopleware recently, and I've just about finished when a thought occurred to me...

Who reads Peopleware?

The book explicitly claims it's principal audience are IT project managers, given the majority of the book discusses how poor application of PM can completely derail projects and the people associated with them. No doubt a secondary audience are people above and below PMs in your typical organization's food chain; upper management and developers respectively. Yet given the principal audience, I don't know of any project managers who have proactively read this book, only developers. This is surely due to the fact that my peer group are predominantly developers, but I do know a handful of professional PMs and some were even unaware of the title 'Peopleware'!

What does this mean? Well, it's possible that I'm associating with the "bottom feeders" of the PM gene pool (maybe I've fallen in with the "wrong crowd", as my Mum was so wont to say), but I don't think so. All of the PM's I keep in contact with are very good at their jobs, to a greater or lesser degree. Which leads me to another, more fundamental question?

Where are the PM geeks?

Most of my developer friends are what I would good-naturedly call "geeks". In other words, they view development much more as a vocation than a profession. Their commitment to development entends way beyond the normal work day and their current project. They spend a considerable amount of personal time indulging in their passion for technology, with the most obvious side effect that they're all extremely capable developers. They think nothing of reading books like Peopleware to gain a better understanding of what factors influence the nature of their projects and how best to maximize the positive ones whilst minimizing the negative. These behavioural patterns contain the true essence of a geek to my mind.

They also spend non-trivial amounts of time reading other developers' blog. So if you're reading this and were in the denial stage of accepting your geek nature, it's too late now :-)

But what of our PM bretheren? Is there such a thing as a PM geek? What activities do they partake to fuel their fire for all things PM-y? Do they volunteer to PM open source projects? Do their congregate to play Risk at the PMI every Thursday night? Do they have vast collections of PM text books? Do they read development text books (or even Leading Geeks) in order to better understand the people they manage and what makes them tick?

I'm not sure whether such a thing as a PM geek exists, saving people like Demarco and Lister and their peers. Maybe the lack of a tangible nature to project management work and the ready availability of a toolset (i.e., their equivalent of the developer's PC and software) prevents such evolution from being widespread in the PM crowd.

Given this, it is no wonder that books like Peopleware are created? If a 9-5 project manager is put in charge of a team of geeks, the impedence mismatch is so large that things are bound to get rocky sooner or later. Where a high performing team normally just needs to have a path cleared for it to get the work done, so many PMs insist on applying their cumulative knowledge to the letter of the law, thus almost guaranteeing friction between the developers and the PM.

And the solution? Buggered if I know, I'm just a geek.

Posted by Andy Marks at 07:32 AM | Comments (4)

September 12, 2004

Refactoring for Fun and Profit

I write this on the eve of what could be an interesting week for my project team: the client has thoughtfully decided to give us "a week off" to spend on the larger scale refactorings our codebase is becoming increasingly in need of. In other words, we have a one week iteration with no business stories scheduled, only technical ones. I'm not sure what the principal reason for this show of benevolence is, but I know our development velocity has been creating a bit of a backlog downstream in the post-iteration/pre-release testing cycle and the team is missing some key people, so we're effectively taking the foot off the pedal and putting the car in neutral until next week.

Whilst the perfectionist in me is grateful for the opportunity to work on some of the larger scale refactors (or restructures, as they should probably be called if you go by the Fowler definition), I see this precedent as a double-edged sword...

On one hand, we have a poorly performing test suite that is in dire need of considerable attention and a week's worth of TLC with a liberal dose of more sensible testing strategies should see us make a big dent in the execution time of the suite. My gut feel tells me that we should be able to reduce the running time (currently in the order of 45 minutes) in half with a handful of big win modifications (e.g., using an in-memory DB, mocking out several external dependencies, etc) which will leave us in a much better position to tackle the smaller gain items as part of normal story development.

As a counterpoint, I'm worrried about the perception of the development team's activities in the larger project/company context. Given that the central concept of refactoring is foreign to most people outside of development, will we be held to ransom the next time we require such work be done? I suspect this entire scenario is a smell that the team has not been communicating the constant need for refactoring and the associated risks of not giving this aspect of development sufficient resources. Time will tell.

Expectation management is an enormous challenge on an Agile project with a client unfamiliar with such techniques. However, it's far less pain in the long run to create the correct mindset from the very beginning than it is to try to correct things midstream once project cultural and operating norms have been established. Drastic changes of this nature can be met with attitudes ranging from frustration and confusion to open suspicion. Even if a particular practice is not implemented in a project immediately for whatever reason, it is vital that it be kept on the radar to reduce the sticker shock resulting from it's eventual introduction.

Posted by Andy Marks at 06:43 PM | Comments (1)

September 01, 2004

The Puritan's Olympics

I might be reinforcing an erroneous stereotype here, but I like to think of myself as being slightly atypical for your typical geek in that I'm a big sports fan. Regular participant until recent years and still avid watcher and generally a fairly active person - the 8+ hours of sedentary coding I perform daily notwithstanding.

So I've been as happy as a pig in mud over the last two weeks watching the Athens Olympics, and in particular those sports in which Australian's perform well, which is coincidentally pretty much all you get to see televised by the principal broadcaster in Australia. Needless to say, if you're not a swimming fan, Channel 7 would have been a fairly bleak option these last two weeks.

But I digress.

Whilst indulging in the games, I was reminded of how much I disagreed with what is included in the current definition of "sport" and how I'd attempted to address this imbalance by codifying what I'll now term Andy's Compliance Test for Sport, or ACTS or short.

In the interest of full disclosure, I should admit that the principal reason for devising the following rules was to explicity exclude golf from the sporting world. Don't get me started on what it is about golf that I don't like in particular, but it's a lot. Suffice it to say that if you're the kind of person who needs a little buggy to save the only real form of physical exertion involved, think nothing of wearing truly hideous clothes for several hours each weekend, perhaps whilst enjoying a few quiet beers on the back nine and still consider yourself a sportsperson... then I have nothing but pity for your empty little life.

Mark Twain was more poetic, but I think my summary takes the points in the venom stakes.

Anyways, personal grudges against golf aside - here are the rules for ACTS. As with most such things, "the judges decision is final and no correspondence will be entered into". If you disagree, feel free to comment, but don't pin your hopes on changing my mind as (to paraphrase my local milk bar's policy on credit) "refusals may offend".

So anyone wanting to apply ACTS to a potential sport can just use these criteria. A sport can only be considered such if it passes each of the four criteria. And for those that don't pass ACTS? Call it a pastime, a hobbie, an artistic endevour, whatever. Just don't call it sport!... at least not in my presence.

Posted by Andy Marks at 12:49 PM | Comments (3)