I’m lucky, very lucky. My life is full of many great things. I have a great girlfriend and the best family a man could wish for, I have a dog that, uniquely within my family, thinks I’m the boss. I’m lucky enough to spend a great deal of time in Cornwall which has captured my heart in much the same way as my beloved Shropshire has. In addition I have a great job which means that on a daily basis I am Sherlock (When I’m not being Batman that is…).
This is not just me trying to increase the readership of my blog by mentioning that heart-throb Benedict Cumberbatch although I am at least guaranteed that the girls within my family will show much more interest in my scribblings than usual! 😉 Maybe even a gratuitous picture or two would really swing the deal….?
Back to me…..So being Sherlock, how does that work? Well, we’re practically the same height give or take half a foot and like Sherlock many software developers have a large anti social facet to their personality! I’m not a sociopath, but then again neither is Sherlock apparently. I don’t have an arch enemy, at least if I have, they have not yet revealed themselves to me. Did you Miss me? Well…. Yes! Its both the nature of my job and my work load that makes me that younger Holmes brother,
In short it is the problems and challenges that I face on a day to day basis. Many aspects to my job I just know, instinctively. Often I don’t need to take that cursory five minutes that is recommended before forming an opinion of any sort. But its all those other times where the magic lies, when I don’t know the answer or where I have only half a clue as to the solution. Allow me to digress a little, there are comparisons to be drawn with my first job was as a baker on a large production line making bread. It was (unlike my current job) tedious in the extreme, that is, until everything went wrong. I looked forward to these meltdowns at which point the work became hot, sweaty, involved, adrenaline charged, boisterous and damn hard work. I thrived on the chaos and catastrophe, I live to be challenged.
These challenges generally present themselves in two diffferent shapes, either of which I love:-
- (System Requirements) Professor Brian Cox shape
- Bugs (Sherlock Shape)
Physics can wait…. I’ll deal with the Professor Brian Cox shaped problems another day, This blog deals only with the Sherlock challenges. These are by far the most exciting, stressful and I would argue enjoyable of challenges. I find that I do need to don my deerstalker, apply my 3 nicotine patches (“its a three patch problem, impossible to sustain a smoking habit in London these days” ) and go “clueing for looks”
Now, I know its kind of not the thing that a software developer should say…but, I do love a good bug. Nobody wants bugs in their code of course, we all do as much as possible to prevent them. There is however an inevitability in them being there. They can be an issue with an external system, issues related to data inputs feeds, environmental settings, and then sometimes they are just oversights. To give some perspective to this I once read somewhere that the average deployed production codebase contained up to 5 bugs in every 100 lines of code, that’s 1 bug in every 20 lines. Food for thought….. maybe you hadn’t thought of having your business critical code audited or peer reviewed before? I bet you’re thinking about it now though!
OK, So. The game is afoot, like Sherlock firstly you must gather all of the salient facts about your issues. “Once you have eliminated the impossible, whatever remains, however improbable must be the truth.”
On some systems this “observe and record” may be as easy as looking at the screen and seeing the issue directly. More often than not though with complex data workflows or financial calculators you may only infer that an issue has arisen by observing a knock on effect of the bug. This is not unlike how CERN captures proton collisions from the LHC. The largest scientific experiment known to man is in the main observing, not observable effects, but secondary and knock on effects from the main collisions which are to most of our senses and systems completely undetectable.
These complex workflows can be fiendishly difficult to track. Often you find yourself relying upon layer on layer of inferred events, much probing and analysis later you get to the truth of what actually happened. Its not unlike quantum theory, until such time as a fact can be proven we must conclude that the state of the machine may be in any one of a number of states, simultaneously.
Its only through observation and careful detective work that we are able to eventually collapse the waveforms of probability and settle on a standard model explanation to continue with the physics comparison.
We must also be prepared to ignore or park some of these observations as they prove to be dead ends or completely different issues. Its not enough to just fix the issue, I would argue that understanding the cause is much more important as firstly you can apply the correct resilient fix, and secondly it helps you to identify all potential failures that have gone before. Fessing up COMPLETELY to an issue is a much better strategy than trying to bury the issue under lies and deceit, you will always get caught out and deservedly so. Ascertaining what is causing the issue is, in my experience, about 90% of the problem, fixing it quite often proves to be very simple and often more time is spent testing, than making the fix.
Finally, we have to document and report upon the issue, Yep… even Sherlock has to do this although he’d probably co-opt John Watson; where would he be without his blogger!? Only when you document it do you communicate it to interested parties and thus round the evidence trail off resulting in trust between the client and vendor. This is the equivalent of Sherlock communicating the murderer, and the motives to Lestrade and the waiting press. The world may not understand Sherlock, nor even like him as a person, but they DO trust his judgement. I guess thats what matters to your average high functioning sociopath.