Tech Answer Blog

Some tech terms references:

Molly Guard: a cover for a switch that prevents it from being accidentally hit. Can also refer to anything that prevents accidental or inappropriate/ignorant/etc. activation of some function.

Junior: an IT professional with limited experience that makes mistakes typical of inexperienced IT professionals.

Cowboy style: A particular junior mistake of going for actions before design, with the justification that any action gets things done faster than no action. While some progress may be made this way, the risk of introducing complex and difficult issues skyrockets.

Crashed: A failure of software or hardware that renders it temporarily useless. Synonyms tend to indicate varying severity of the crash: Borked, Hosed, Jose’d, Dead, Toast, etc.

Bricked: A particularly bad failure that results in the computer or hardware rendered completely useless. The saying implies that the computer would now be suitable for the equivalent uses of a clay-fired building brick.

In response to Paul M. Ingevaldson’s article in the October 29, 2007 issue of Computerworld, I have some troubling insight to present.   Suppose an IT worker is stuck in an environment where their management refuses to decline a customer’s increasingly absurd requests.   Likewise, ever increasingly absurd time and budget requirements are expected to be met.   I argue that this is increasingly the case in swaths of commercial IT and development contracts.   Good contracts and positions exist, but how can a worker reverse or combat the effects of these trends, assuming they are reluctant to leave their current position (for whatever reason)?

I agree that tactfully discussing the reasons for saying ‘no’ on any and all necessary items is a start, but there must be a more concerted effort to involve the team.   Make sure that everyone knows that the actual spec the team considers relevant differs in key metrics from the spec that management agreed to, and refer to the actual spec in all possible meetings where the artificially low deadlines are pressed.   This way, the efforts of IT to produce good estimates and the reluctance of others to accept those estimates can be addressed and brought out in the open.   Of course, there may be contract disputes or other political issues afoot, but the programmers and system administrators cannot be expected to answer for unrealistic specifications and deadlines.

Moral: Just because it takes nine months for one woman to have a baby, that doesn’t mean you can produce a baby in one month from the efforts of nine women.

11/6: I’m starting work on diagnosing a cable tv dvr issue. I’m getting no error messages, but I’m not able to record shows. I can set the record indicator, and I can watch previously recorded shows as of when the problem started. I will report the resolution of this issue in this post when I get it resolved.

11/7: solved with a reboot of cable box. Powered it down, unplugged it, waited 30 minutes, plugged back in, and now DVR is working.

Managing risk in technology is exactly like taking care of a small dog. There are only two ways to handle a dog’s needs: proactively or reactively. If you assume you can tell when a dog has to go outside, you can try to only take the dog out when you see those signs. However, no matter how attentive you are, you will inevitably miss some sign and the dog may have an accident inside. To combat this, you must take the dog out when the dog isn’t exhibiting any signs of having to go out. Technology issues are similarly unable to voice every single time there is a vulnerability being exploited. The best hacks are the ones you can’t see at first glance. Therefore, initiating proactive risk management (PRM) regardless of signs of problems will provide the best safety dragnet for any tech risks. For example, PRM insists that unit testing must be comprehensive and run on a regular basis to be effective. Think of the number of errors that still creep in because someone didn’t make or run a good test on the functionality they added. This testing is a required component of software design when implementing a PRM strategy. In the extreme, reactive vs. proactive risk management is about gambling. Extremely reactive risk management is taking a gamble that if something bad will happen to your business or technology strategy, it will be a minor problem. Extremely proactive risk management is gambling that something bad will happen eventually, and so you should create mitigations for serious problems before they actually happen. Thus, the extremely proactive cannot guarantee they won’t get hit by something bad any more than the extremely reactive. However, the extremely proactive will have a workable solution when they are hit by a bad risk, whereas the extremely reactive will have to come up with a solution after the problem has hit.

The purpose of KB 301429 is to help resolve the msxml3.dll error 80072f0c, which means that the client certificate of IWAM_ is not installed. Their steps are missing one element: Once you install the certificate, click on it, click advanced, and select the checkbox for “allowed for client authorization”. If you don’t do this, then even if you go through all the other steps, you’ll still get the same error. It took me a LONG time to figure out why their fix wasn’t working, so I thought I’d share the end result with everyone.