You would think that there had never been a problem in the DP (oops IT) industry before.
But a whole new range of "management tools" have surfaced.
"Artificial Intelligence is no match for natural stupidity."
The objectives appear to be to produce cost estimates and a Project Plan to discover if an entity has a problem and to quantify the problem. In themselves good objectives.
Overplanned, Overmanaged are words that spring to my mind.
But we are not examining the crucial issues. We are adopting tools because they are there, not because we need them. As a problem Solver I use the tools readily and easily available. Even my wildest critics would never accuse me of language or tool bigotry. But what is the target objective?
I get the impression of Fiddling while Rome Burns.
Vendors are springing up with a plethora of scanning tools. This is good. Scanning can identify potentitally problematic fields. But you need to know what to scan for.
I get the impression that people are not sure what to do about the Y2k problem, so they feel better if they go out and buy something. The more expensive the better.
I call this sort of thing " Feeding the Crocodiles".
(There is an old saw that goes "When you're up to your arse in Crocodiles, it is difficult to remember that your objective was to drain the swamp").
Now it is an established fact that the main objective of the Human Race, particularly when huddled together in masses called companies or corporations, is to promote Conspicuous Consumerism.
(We have optimised The Female of the Species for this process. Girl Children now enter the world with "Born to Shop" tags on their cute little toes) B>)
When in doubt, Feed the Crocodiles. It gives you something to do.
The next Phase that is being sold is the Inventory Phase, closely followed by "Solutions" and "Conversions" and "Testing".
I have no problem with the Identification or Inventory phase, but have grave reservations about the assumptions that are being made on solutions.
Until the proposed new Operating Systems are delivered and up and running it is speculative at best to propose solutions, let alone conversions.
I recently saw some code samples for the "new" COBOL date solutions. They bear no resemblance to the "old" type code.
There are new verbs, new call sequences, new techniques, new assumptions. This is not simply expanding the length of date fields, this is new logic and design. I do hope people have not been changing their systems based on the wrong assumptions. I do hope all these new Commercial "Tools" are based on this new reality.
I have experienced similar scenarios. In the 80's we had a major architectural upheaval with the announcement of the IBM 4300 series. This involved a major systems software change.
Based on prerelease documentation we planned and converted our systems in specific ways.
When the tapes were loaded we then discovered problems in getting things to work.
The learning curve was very steep. The software was unstable after undergoing major surgery and out interpretation of the documentation was in some cases ridiculously wrong. In some cases the prerelease documentation was just plain wrong. Things had been planned one way, but implemented another. We had to re-plan, re-educate and reimplement our previous migration plans.
I see similarities in what is now happening. When the New Operating Systems begin to arrive in second quarter 1997 we are going to see what comes crawling out of the woodwork.
Several major problem areas such as file expiration have (to date) still not been resolved. Experience suggests that major changes to an OS produce results which are unpredictable.
I suggest a "cooling-off" period before we go in and change any more code. Let us test what we have in the new environment and then make some rational decisions.
Thankfully this is not my main line of business (by choice) so I can sit on the sidelines and kibitz.