CogTools - This Is Why We Can't Have Nice Stuff

129.4 hours of work in a 14 day period (not bad, considering all we got done!!).  Throughout this week and the last, I have had a bit of time to reflect on just how much time it takes to learn the simplest things, (and retain them for later use,) when your brain is inundated with new or different information.  

Day to day tasks when working with software are usually considered routine or mundane, but when one has to trouble-shoot issues the brain gets involved in a deep problem-solving of software or extraneous network issues.  De-bugging software anomalies presents a very interesting dilemma (CHALLENGE) for those tasked with it. For those who are not skilled with the aptitude afforded to those with software engineering, computer science or similar backgrounds, de-bugging and trouble-shooting system issues is an arduous task.  With potential issues that become known when working on closed networks, through a multitude of domains, hosting disparate software packages, with varying levels of privileges… levels of socket layers, firewalls, installed software package accessibility to execute commands across domains, etc… issues may seem to be endless to track down the root-cause of.

Even the simple act of “remoting-in” to another machine across a different network can present potential issues.

Isolation, may be the key.  Not isolation in the sense that the trouble-shooter is isolated, but isolating the components that are NOT the cause (or potential cause,) of an issue may become the most helpful in trouble-shooting system issues.

It seems obvious enough, but if one can isolate what is NOT the source of a perceived problem, then it is easier to employ process-of-elimination to identify anomaly sources.  One may have to look at ALL of the most minor details to get at the root of a problem.  In many ways this is a test of active learning coupled with the patience required of trial and error.  For many technology trainers and SA’s it would be hard for them to list and quantify all the ways of going about how to solve a system problem they are responsible for.  

 In most cases it seems, SA’s will employ memories of past issues and their resolutions to formulate a plan for attacking current issues.  In this way, one can mark-off and identify any system issues caused by the usual suspects.  Specifically, this refers to past issues that have not been properly worked through (and thus, the resolutions to them haven’t been completely solidified,) and removing them as possible causes of the current state of breakage.

I would identify much of what was mentioned above as fact-finding or fishing trips.  Depending on the complexity of what is being worked on, the first stages can probably be completed by a single person, while later success will usually involve multiple people working together to detail the holes in previous information.

It is easy for one to take for granted their software working cleanly with other kinds of packaged software, but when this is coupled with disparate versions, timing requirements, privileges, licenses, OS’s, etc. one can have a plethora of potential sources to isolate as the culprit of any number of system issues.