|
|
ABCnews.com has an article today (12/14/1999) headlined, "Y2K Cure may be worse than the disease."
Duh! Any experienced software developer would expect the kind of problems that the article describes, especially considering the inadequate testing that I have witnessed.
I have been in IT longer than I want to admit. One of the first things I heard, and I don't remember where or from whom, was that "Every bug fix introduces two more bugs that you don't know about."
Now, I think that's a bit extreme; in my experience, I would say that it's more like, "Every two fixes will cause a problem that can be uncovered by a good test plan."
But see, there's the rub. The test plan should be done at the same time as detailed specifications are being developed. If you don't know what you are trying to develop, or correct, in the case of Y2K remediation, then you don`t know what to test. How can you expect to have a successful remediation effort without doing this?
I have seen the test phase of three-month projects scrunched down to a couple of weeks. A good rule of thumb is that if it takes three months to develop or fix something, then you should allow three months for alpha, beta, and final acceptance testing. This is almost never done. I had a stretch of about three years where everything I did went into production without any bugs because the clients followed, or at least made a good effort at following, that testing philosophy. I am excellent at unit testing and working with users to resolve identified anomalies, and I still have most things go into production with no bugs because of these joint efforts. However, some software requires the end user to exercise the functions in the way they are used in the real world. It is impossible for a consultant on a three-month contract working on an application with hundreds of screens to understand the ramifications of changes to one program. As an example, quite often a change to an Accounts Payable program will affect a General Ledger process. This may not be obvious to the end users, who typically only know their application, much less a short-term consultant. Final acceptance testing of all application components, even those not modified, should be part of the project plan. Every book I've ever seen on the subject agrees. So why do project managers yield to pressure from others to cut corners, knowing the results? They don't seem to realize that six months down the road, people won't care that the project took another month; but they will most definitely remember if they could not use major parts of the system (i.e., post to GL) for days after the modification was installed.
There are other factors at work here, one of which I'd like to touch on because it applies to all projects involving contractors and/or consultants. When I first started contracting years ago, almost all contractors were experienced professionals and tops in their field. There were a few weirdoes and non-productive types but they were weeded out pretty quickly.
Now, there are a lot of inexperienced people lacking the required technical knowledge. There also seem to be a lot of misfits who are contracting because they interact well with computers but not people and so have to move on. If you see a resume and the person has never worked a one to two year development project, that should be a red flag. If most contracts were 3-6 months, that's OK, but there should be at least one long-term contract. Also look for multiple contracts at the same client, that indicates that they do good work and don't have to be hid in the attic with the crazy aunt.
That's a digression, though, from the main point I want to make here. Do not make the mistake of not managing your contractors. Verify in some way (like testing) that they've done what they say they've done. I have paid the price many times for the work of these bleeps, going in behind them and trying to figure out what they actually had done and how to salvage the project. I actually had to leave a project once because of a situation like this. The client had used a part-time contractor working offsite. Supposedly, all programs had gone through a new source code check in process and anyone could find any piece of code easily. I spent my first week there trying to determine which database schema file was current. (I know I've lost you non-techies, but just stick with me and I think you'll get the gist of it.) Most of the programs that I had to change for my first project were not checked in, so it was impossible to determine which source code to change. I told my boss about this, saying that we needed to stop and identify current source before continuing with any new project. She adamantly insisted that this was done and I needed to start making changes. So, I found another contract. (Another lesson: be big enough to admit when you're wrong.)
I am not saying to look over people's shoulders all the time, but verify that things are as you are told they are. In the unfortunate incident above, all my boss would have had to done was to ask the source code librarian to make sure that everything had been checked in. If I had been the previous contractor, I would have appreciated someone double-checking my work to make sure that I didn't miss a program anything. But then, "walkthus" are another discussion and I leave that one alone.
The need for oversight also applies if you outsource projects to Big Six companies. Although they are being paid for managing the project as well as the development, remember you cannot delegate responsibility. If you don't, you may be reminded of it at your next review. Also remember that the number one job of any Big Six consultant at a client is not the project they are being paid to work on, but to find more work for their firm.
The article at ABCnews.com is right on; a lot of companies are going to have unpleasant surprises in a few weeks that are seemingly not Y2K related. There aren't any guardian angels for clueless IT managers or those who know better and cut corners anyway.
(c) 1999 Suck It! Webzine