Archive for February, 2007

Scott Hanselman’s latest podcast on end to end tracing got me thinking about the need to capture tracing information.  Sometimes, despite our best effort, we are unable to reproduce issues encountered at customer sites.  When that happens, what can we do?  Collect some debugging/tracing information, that’s what!  If you are lucky, this will help you pinpoint the problem in the deployed system.
In our system, we can turn on different levels of debugging for the various components of the system.  Simply edit a text file, add a few simple lines, restart the program and reams of data gets collected.

What is wrong with this picture you might ask?

Two things:

  1. It requires editing a file – even if it’s simple, even if you can coach a user, they don’t like it
  2. It requires restarting the program.  Sometimes, this is simply not acceptable.

Remember, we’re not talking your development environment here, but a live, running system!

In our case, we decided to put a simple radio button group with 4 options:  No tracing, low, medium and high tracing.

Yes, we loose granularity on controlling which components trace, but the trade-off is more than worth it:  No files to edit, and no system restart.  Makes the customer happy, and gives the engineer the information they need.  What more could we ask for?

We got this one right under the wire, thanks to Harry Connick Jr.’s New Orleans Tour.

I would point you to Roy Osherove’s entry on Object Oriented design for Testing.  I like it!

Just finished listening to Scott Hanselman’s Hanselminute #49 with Bruce Payette – interesting stuff about PowerShell.  A new book I just have to have.  If you’re an system administrator on Windows, do yourself a favor and learn PowerShell.  Your life will never be the same.

Today has decidedly been an interesting day…one where no matter how much I wanted it, a device simulator was simply not going to do…real hardware reared it’s ugly head and I had to break-out the oscilloscope.

You would think that a small PIC processor running at 8MHz would be able to handle the requirements for the Dallas 1-wire bus.  It worked just fine with the serial-to-1-wire converter we use. Unfortunately, hooking it up to our embedded controller caused the integration blues to burst on the scene.

Our controller uses a Dallas (now part of Maxim) DS2482 to do the interfacing from the processor to the 1-wire bus.  That device definitely has its quirks!  The trouble we ran into: the DS2482 has much faster transitions than the converter we were using for design.  Turns out it was too fast for our 8-bit processor!

5 different permutations of assembler instructions later, the problem was fixed. And you think software is a handful! Hah!  But this is what makes embedded a challenge!  Do you have what it takes?

Joel Spolsky strikes again with a well timed article on customer service. While I don’t always agree with Joel’s take on things, this article will resonate anyone having had to deal with corporate customer disservice departments.

We use Fog Creek’s Copilot system and we are very happy with the results. For a measly monthly fee, you get the ability to remotely log into your customer’s computer and diagnose issues. This has saved both us and our customers tremendous amount of time.

As luck would have it, we had an incident last week where the service would not work at a “batten down the hatches, the internet virus hordes are coming, our users should not be able to do anything, especially not surf to hotmail” location. On the phone to Fog Creek’s tech support line we went, and while they could not fix it – good customer service is no talisman against IT policy gone awry – they were very pleasant.

Not 24 hours elapses where we experienced strangeness at a different site. Not fatal strangeness, merely inconvenient. Back on with Tech Support, they went and checked with the development team. I wonder if they went to the communal lunch table (as this was 12:15) to check things out.  Turns out, it was probably caused by a slow connection.  Restarting the session did solve the problem.  Not only did they point out a potential solution, but to compensate for my inconvenience, they did not count the hour+ I spent in my customer debugging session against our service.

Since I like their products, and we are looking to fill a vacancy, I thought I would give Joel’s job board a try. So far, I have been very satisfied with all their product, and unlike Dice and Monster, I know that the people looking at his job board did not just graduate from high school.  Besides, he offers a 90-day no questions asked money back guarantee. If we don’t find anyone, it will end up not costing us a dime… Try to get that from the big boys.

Scott Hanselman has a great blog entry titled “The Programmers phases of Grief” (via The Daily Grind) to which I can totally relate! I’ve been there before… However, what struck me most was Scott’s opening sentences:

One’s mind should be pretty clear when programming. I’m a decent enough programmer, but I’m not a bad-ass programmer. At least not anymore.

Back in the day, before marriage, before diabetes, before babies, when I was sleeping a full 8 hours, I could code some nice stuff. Now it’s just a miracle it compiles. When it does.

And furthermore, I can so totally identify with the Depression stage:

I’m not a good programmer! I’ve been coasting on charm for at least the last three years. I remember what closures were in college, but I’ve been using .NET 1.1 for the last five years and it dulls the senses…I might as well just give up and become a nurse.

The man must have read my mind! I believe we all occasionally get plagued with self-doubt. What value am I providing my employer? When you’re in this stage, you tend to feel like you’re not doing enough, not providing enough value. I’m not a superstar programmer anymore! :-(

The reality is, if you have been with a company for any length of time, your value does not just lie in what you can produce right now, but also in the sum total of the knowledge you accumulated. This has recently been vividly illustrated at my employer when one of our Application Engineer moved away. He had been with us for 3 years, and during that time he became very proficient with our various product offerings, and a main part of his job was to provide technical support to customers. Alas, with his departure, we are left somewhat short handed. While we have new personnel on board, it will take a while for them to accumulate enough of the knowledge to be able to provide good support. This increases the pressure on the rest of us to pick up the slack. And unfortunately, this intrudes on our productive hours. Which feeds the feelings of inadequacy…

I’ll just have to pick myself up by my bootstraps and keep on plowing!