Why is it that a tech support problem doesn’t become an emergency until it’s most inconvenient?

I was quite literally standing up and collecting my wallet to go to lunch when I got approached by one of our support people and a fellow developer with a problem at a partner site. They described the problem and asked if I can log on to see if I can figure out the answer. I asked if it could wait until after lunch, and they said no because the system is going to be packed up and shipped to the evaluation center and it has to be working by then, and so we’ve got a 1 hour window to get it working.

So I go over and get Bob to log me on, and at first I’m lost. The subsystem that sends back the heart beat from one system to the other was the responsibility of a programmer who doesn’t work here any more. The log files don’t help much. But one thing I notice is that according to the logs, they’ve had this problem as far back as the logs go, about 14 days. Ok, it’s been a problem for 14 days, but evidently you can’t be bothered to fix it until there is 1 hour to go before an irrevokable deadline. Why is this my problem again?

I do some poking around a config file that I’ve had very little to do with in the past and I notice something glaring – the system is configured as [system] “2”, but it has another similar parameter set to an id of “1”. Ok, leaving aside the little question of why there are two parameters that control the same thing when one could probably be derived from the other, is this it? I change the second parameter to a 2 and restart it. And almost immediately start seeing heartbeats coming.

I’m out of there before they can find something else for me to work on, and the cafeteria doesn’t close for another 45 minutes. Yeah, me.

User interface design for programmers with no sense of style

Years ago I was working on Kodak’s Cineon system, an innovative system for digital post-production of movies. It was a great gig, but unfortunately Kodak pulled the plug because there were too few post-production houses doing digital work to support a competitive marketplace, and because some really questionable business decisions were increasing the development costs. I still think they should have held on a bit longer until the market caught up to us, but that’s life.

One of the projects I worked on was a “clip editor”, where the users got a view of multiple film clips (ie. different shots from the same scene) and they could cut them, shrink or expand them, slide them up and down relative to each other, and then define the transitions between them. Our competitors called theirs a “virtual light table” or something like that. Ed Hanway was doing the guts of the program, and I was doing the user interface. I liked working with Ed – he’s one of a handful of people I’ve worked with over the years I’d consider as good if not better than me, and easy going and easy to get on with in spite of it.

I had the basic outline for what I wanted the clip editor to look and work like, but I felt that my own aesthetic sense was lacking (which you’d agree with if you’ve seen the way I dress), so I wanted some feedback on the aesthetic aspects of the design. Kodak didn’t have a Corporate Design and Usability department like they do now, or if they did nobody was telling me about it, but since the Cineon tech support department was staffed by people who edited movies, I figured they’d have some artistic instincts.

Oh quick aside here – our tech support people often pitched in at customer sites when they were using our software on big projects, which meant that you could always tell the Cineon people at a Rochester movie theatre, because we’d always wait for the very last credit and cheer when it had one of our people’s names.

But I couldn’t get anybody to answer any of my questions. So I figured I’d force the issue by choosing two of the most hideous colours I could find. I think I chose two that had pre-defined colour names in OpenGL, but I toned them down a bit because the people using our software always seemed to do it in dark rooms and the rest of our interface was in shades of grey because of that. I think I ended up with a sort of mauvey-pink and a light limey-green. I knew *somebody* would have to complain about these colours, and then I could ask them what colours they thought it should be.

Oh, another aside – the program had been started at Kodak’s Australian office, and then moved to Rochester, and then we had some code contributed by the office in London England, and then half the development moved to San Francisco for no good reason. One of the things that led to was continual problems with the spelling of the words “colour” and “grey”. You’d find both Commonwealth and US spellings of both those words in method names, and sometimes both variations in the same method. The method name confusion was the worst – you’d write your code to call “adjustColourSpace3D” only to have the compiler bitch because you meant to call “adjustColorSpace3D”.

But I never got any complaints about the colours, so that’s how they went out in the release. And a year or two later, somebody brought some literature back from our big trade show, ShowWest, and lo and behold one of our competitors had copied my hideous colour scheme in their virtual light table.

A few weeks ago I was telling this story at lunch, and one of the other former Cineoners who got to go to customer sites mentioned that the customers had loved my hideous colour scheme because of how well it stood out. Huh. Who knew?

I guess the secret to good user interface design is to purposely make something that offends my senses, and I’ll come up with something that normal people like.