3 Responses to “Biggest IT blunders – do techies make them?”

1. S.Lynn Says:
   December 22nd, 2008 at 2:43 pm

   Strangely – I saw #1 happen – to our CEO – by our IT Manager.

   Oops – make that FORMER IT Manager.

2. J.D. Sherling Says:
   September 8th, 2009 at 3:49 pm

   I truly wonder how many of these ‘math blunders’ were related to improperly constructed Excel spreadsheets?

   J.D. Sherling, C.P.A.

3. Charles M. Barnard Says:
   October 19th, 2009 at 5:07 pm

   Sorry, but most of these “tech errors” are management errors.

   # Deleting a top exec’s files without a backup.
   Can happen–sometimes even if the backup was made, it fails. The really serious errors in any field usually involve a sequence of individually unlikely events. (More below.)

   # Going along with a company that refuses to embrace best practices.
   Most programmers would be out of work if this were practiced.

   # Creating documentation that no one else could understand.
   Not the IT person’s responsibility, it is management’s responsibility to review documentation. Techs write poorly for the most part, and NO ONE should release documentation which hasn’t been reviewed by people ignorant of the functions described to determine whether or not the documentation is clear.

   # Taking backups for granted.
   Oddly, in over 20 years of consulting, I seldom found a company which was properly backing up their systems (to the point I made checking the backup procedures my first concern.) Many back up data without realizing that they must have copies of the creating and using software that are contemporary with the data–or they will be unable to use the backup. But back-ups are the responsibility of operations and management, not the techies. Workers using the system should be able to take backups for granted, backups are a service performed by operations.

   # Failing to take advantage of free training opportunities.
   This is often not the employee’s mistake, but the management’s. Managers in many if not most companies fail to plan time for continuing education, and succumb easily to the lure of “finishing up” a late project (are any projects NOT late?)

   Additionally, I learned early in programming not to ever present a manager with a version of the program which looked complete–commenting out completed code in order to maintain the ‘unfinished’ status of the software if necessary. Managers are all too ready to release software which ‘works’ even though there are still major issues (often error handling) which have not been dealt with…. Documentations is another step likely to be skipped over by management in order to get a release out.

   The results are never pretty. Sending out unfinished software means lots of wasted time hand-holding users or recovering from errors–usually far more time than would have been required to properly write the stuff in the first place.

   I have never been called back to troubleshoot one of my programs…wiith one exception. The company had made a very bad technical decision regarding field usage, and run completely out of binary codes to us as a warehouse number. To repair this, they went through and expanded the two byte field to 6 bytes, in doing so, they missed a temporary holding variable in my program, spent 30 days trying to figure out what they had done wrong, and finally called me in to fix it, which took me 2 days.

   Management is under a lot of pressure to get stuff released, but writing software is nothing like machining parts–it’s a design process, and it is possible to go down quite long wrong turns for any number of reasons.

   Example. I worked as an outside consultant for a major software house. One Friday afternoon, they pulled 14 of us off of our current projects, handed us a stack of program change requests (about 1500 pages) with orders to give them estimates by the end of next week.

   Most of the changes were dated at least one year earlier, and it turned out that their internal people had been working on the project for 18 months (and $8 million of the client’s money!) The client was understandably unhappy with the lack of progress.

   We split up the pile, and produced estimates. We were in an office area which had recently been abandoned, and which the company had not decided to renew the lease, so it was pretty shabby–worse, there was one (1) phone for the 14 of us, the only copier was one floor down at the far end of the building and we had no secretarial services. Having inherited the phone, the same way the only person on site at 4pm the Friday they handed us the project became project leader, I became general fix-it/secretary.

   All of the sheets we got were classified “A” “B” or “C” we made the mistake of assuming that these were priority classifications (since we never were permitted to talk about the project with the original team, lots of stuff was very unclear.) I had taken a bunch of the “C” sheets to estimate (in my ’spare’ time.)

   One change sheet I estimated at about 2-3 days, was a single line stating that a set of temporary numbers assigned to various jobs in the scheduling module should be carried through on a report elsewhere in the system.

   I kept a bunch of the “C” jobs for myself to work on, and this one was one of them.

   The program (and I use the term lightly) consisted of 72 subroutines, only 2 of which were called more than once. The vast majority of them consisted of whole sections of other programs lifted and installed into this patchwork. Analyzing it was a nightmare. I had very early decided that the easiest way to implement this was to store the numbers in their own file, and access it where needed via subroutine.

   I spent nearly 2 weeks trying to figure out exactly WHERE in the mess the numbers could be extracted to a file.

   Then I turned it over to the client’s technical person, and was promptly told, “:Oh, no, that has to go through and appear on ALL of the intermediate steps too.” And “It is central to our use of the program that this functionality be included–without it, we cannot use the software.”

   “C” was NOT a priority indicator. “C” was a implementation timetable indicator.

   I immediately went through the system to determine where changes would be needed, finding 450 programs which would need to be changed. I immediately took the information to our (new that day) project manager, with an estimate of some 800 hours to complete the changes. Being the bearer of bad news, I was off the site that afternoon.

Leave a Reply