Forensic Software Engineer

I’m not sure that’s an actual career, but it needs to be.  It’s what I spend at least half my time doing.

By that I mean I tend to get given “processes” that someone else used to have before they quit , were fired or made such a mess of it that it was taken away from them.  Then I’m told to “make them work”.  But the majority of the time neither the people who used to do it nor the people asking me to take it over actually understand how “it” works.

So, the biggest challenge in taking it over is to find out how the thing works, how it’s supposed to work, and therefore what to do to “fix” it.  That involves lots of digging through code and the rare small scrap of documentation (ha!) to figure out the inner workings of the process.  It’s a tedious process at best.  Sort of like trying to figure out what killed something long after it died….forensic pathology for software processes.

Along the way you tend to find some facinating choices for how to do things by the previous owners.  If you’re lucky and you still have access to the previous owner they might actually own up to the fact they didn’t really understand it but just plowed ahead with it never really knowing enough about what was happening to question the results.  More often, however, you have no access to the previous owner or they are less than forthcoming with the fact there are major aspects of that broken process they don’t really understand.

As I like to say, I could complain but it wouldn’t do any good….