Technical Litigation

Disclaimer: I do not take credit for this term, I first had it explained to me by our vice president of operations at my current employer.
Everyone thinks they are special. You can have an application doing the same thing for hundreds of customers and each one thinks that the unique problems they are experiencing must be your fault. Quite simply, technical litigation is the process taken to prove that [technical situation X] does not lie within your jurisdiction of control.

Recently, I wrote two programs for the single purpose of technical litigation. I spent approximately 3 hours of my 12 hour workday writing code to prove a point. The first program simulated the digital signature component of our testing environment. In reality, after I pulled the correct data the coding only took about 30 minuets. Still it was time I could have spent doing other tasks that would have a more long-term impact. The second program was designed to prove that the way we base64 encode some binary data was correct. This second program compared byte lengths and hashes of the decoded strings from four different base64 decoder implementations.

To be fair, this is an atypical example but I would say that roughly 10% of my time as a developer is spent dealing with issues of technical litigation. I am admittedly curious how much other organizations deal this issue - particularly among developers. During the course of technical litigation I have learned a few things from my experience:

#1 I tend to pursue problems differently when I hold the premise that I'm not the one at fault.

I can't really say why, but I have a tendency to be more methodical with problems that I don't think I caused. It is almost as if I have a clearer mind when I am looking at someone else's mess. Maybe it is the the fact that personal emotion is taken out of the situation. Maybe I am not distracted by the possibility of learning a hard lesson at the end of the day. Maybe it is simply my professional inexperience. I cannot say definitively, but the fact remains that I approach problems of technical litigation very differently.

#2 My job is to attack the problem, not the customer.

This is not something that I have a major issues with, but I can see that there is a natural competitive tendency to beat the other side when trying to prove a point. When the other side helps pay your salary then it it important to look at them as a partner who ultimately wants the same thing you do: for the problem to go away.


#3 Pointing fingers is never more important than moving on.

I learned this by observing breakdowns in #2. Whether you are a developer, a customer, or a manager, accepting responsibility is often a difficult emotional process. The end goal of technical litigation should always be a problem resolution. Technical litigation should be though of as simply a middle process to determine who needs to do the solving. Therefore, once the responsible party has been identified, there is no need to dwell in the technical litigation phase. Pointing fingers and arguing will delay the problem solving process and will not benefit either side.


#4 Admit when you are wrong.

This closely ties into point #3 but is in my opinion the most difficult aspect of technical litigation. The software industry attracts many individuals who have a dominant "C" personality (refer to the DiSC model). The high C personality values accuracy and detail which gives them an advantage when working with complex technical concepts. Given that accuracy is important to the C, it is often much more difficult to accept being wrong.