Know Thy History

I’ve been having some transient issues with my cable modem connection as of late and as such I’ve had quite a few Charter tech’s come out to my house and look at the my connection. Twice was the same tech and the other times it was one I’ve never seen before. This brought into view a very important issue in both software development, cable internet repair and life; know some history!

The Charter tech that came out knew nothing about what the previous tech did, and really didn’t seem to care. I tried explaining to the new tech what the old one did and what he found; I even offered him the other tech’s cell number, and he couldn’t seem more disinterested. The new tech then proceeded to waste time re-doing all the work the one did and came to about the exact same conclusion. This is something I see play out quite a bit in the software development world and is something I try to be aware of.

Because you don’t know the history of a problem or why something was done a certain way you may try and ‘fix’ it and end up breaking everything. For example I used to work for a local casino and there were a number of times where some equipment was strangely configured or wired weirdly. If I didn’t ask why it was done this way, I could have made some huge mistakes. At my current job we have a wonderful resource, a person who’s been on the project from day one and pretty much and tell us why something was done a certain way and we’ve gotten in the habit of asking him before we start making changes, so we can know the history.

The flip side of this is you need to have a resource where your history can be accessed. This is either a person or a system, but it is a must have. At my work we have a convention where if your writing some code and it’s less the obvious why it was done this way it needs a comment to explain it. There are plenty of ways to record this information, screen casts, version history, trouble ticket systems, etc. This should be a requirement to record important history or even things that may be important, and needs to be fostered in your organization.

For Charter, they should have a system where tech’s are required to enter notes and new tech’s are required to read them before going on site. This would have saved Carter a few hours of paid tech time and allow them to move onto other jobs quicker. But instead, I’ll wait for the new tech to come out and check my coax wires, connections and cable modems again for the third, err, fourth time.