The Mu

If there were a programmer action doll, it would utter “MVC is hard” just like Barbie did.

There’s some interesting psychology behind why it is difficult to discipline oneself to separate code into the different concerns of software (not just model-view-controller, but also cross-cutting concerns like persistence and security). One of the best explorations of this topic came in an interview I just read.

Terence Parr (the interviewee) is a bright guy. The interviewer is a pragmatic guy who makes reference to his team’s use of the Velocity project, which I was lucky enough to see a quick demo of this weekend. Velocity is a Java-based template engine; it lets programmers use a template language to reference objects defined in Java code.

StringTemplate is Parr’s creation, and it provides more enforcement of the separation of concerns by driving more function back into the model, where he says it belongs. He states his agreement in principle with Velocity’s creator, Geir Magnussen, but at the same time has been more ruthless in StringTemplate’s approach to simplicity and separation.

I have no idea who has a better approach — I have yet to see StringTemplate in action or actually use either technology directly, but I can completely agree with Parr’s assessment of how programmers slide down the slippery slope of intermixing function that is best kept separate.

There’s a good chance all tech support centers have the classic collection of stupid user stories circulating around. You know, the one about the person who uses Liquid Paper on the monitor to correct an error, or the one about the person whose “retractable cup holder” was broken (in fact it was the CD-ROM drive simply stuck in place with spilled coffee).

As a counterpoint, there are equally horrendous stupid tech support stories.

I remember when my office location had really poor tech support. The help line was definitely no help most of the time. But then, several years ago, they made a concerted effort to hire and train some quite talented troubleshooters. There is an art to leading someone through a series of steps to get resolution to a problem. This art becomes especially challenging when the users are technical people themselves, like most of the people in my office: the know-it-all factor gets in the way.

There is no glory in a tech support job. You’re going to face rudeness because people only call when they’re already frustrated. You’re never going to know all the answers. The tech support people who do rise above their colleagues are quickly promoted into more challenging roles. So the front line people on the phones are rarely either highly skilled or highly experienced.

I have come to appreciate the hard work that the person on a tech support line has to do. But I also wince just as badly as anyone else when I face a clueless noob. Of course the worst are the clueless who have the overtly stated conviction that they know best.

Edit: After posting this, I found a post and series of responses that really shows both sides of the argument.