Customer Service and Automation

In an ideal world, application maintenance in the enterprise focuses primarily on making an in-production application operate better by pursuing the 20% that other people can’t. In reality, that is something we get to do PART of the time, but there are huge chunks of time that get spent on client service instead. It can really suck the satisfaction out of the job at times.

“Support” isn’t all bad, though. Sometimes being in the line of fire gives the working programmer a chance to fix a process or build a tool that has a lasting impact on an organization.

Take Chris, for example. He’s a plain old engineer by training, but like most engineers born after the birth of the PC, he has gotten his hands dirty with a little code from time to time. I have often heaped abuse on the code turned out by his ilk, but the truth is, it’s not all bad. Chris turned out some Excel tools that did a ton of work for him. One of them was pulling and analyzing files from a document control system and measuring properties of solid objects in a way that I simply wouldn’t understand.
Programmers of that type are valuable for their ability to create tools that encode deeply domain-specific knowledge in an automated way. As a maintenance programmer, I value that kind of code, because it automates something I might not even understand.

One of the ways to gain understanding, however, is to live in front of the support firehose. Chris’s tools almost always came out of a repeated request from his fellow engineers. Sometimes they needed a set of files copied to a particular location. Sometimes they needed to convert files to a new format. Sometimes they needed a way to move data and files to a new location.

Each time the request came in, another little piece of the requirement showed through. Sometimes the next step was to automate the support process; sometimes the business got there first and requested a tool to meet a need that was immediately recognizable as the same kind of thing as one of Chris’s tools. Whatever the sequence, the fact that Chris lived in the support stream meant that he had that deep understanding of requirements I talked about, and that meant he could use his skills as a programmer to build something that made a material difference to the life of the support guy (himself, in this case).

I’m about to enter that support stream. In days gone by, I think I’d be disillusioned. But having spent the last several years learning what I’ve just talked about, I now see the opportunity I’m being presented, and I’m excited by the possibilities.