My assertion: Y2K glitches will lead to formal software disciplinesgreenspun.com : LUSENET : TrendsTeam : One Thread
ASSERTION: POST-Y2K PROBLEMS WILL FORCE IT TO ADOPT RIGOROUS SOFTWARE ENGINEERING DISCIPLINES
Predictions about the outcome of Y2K range from BITR (bump in the road) to TEOTWAWKI (the end of the world as we know it). But the contingency plans and the SEC 10-Q statements from Fortune-1000 companies suggest a common consensus that there WILL be problems during the coming year. Obviously, some of the problems will occur at the stroke of midnight on 31 December 1999; but others will occur throughout the month of January (e.g., on the first day of business on 3 January, or when the payroll system is run for the first time, or when the accounting books are closed for the first month), and February (e.g., on February 29th, which may or may not be recognized as a legitimate Leap Year date), and March (e.g., when the books are closed for the first quarter), and beyond.
If indeed Y2K turns out to be a mere BITR, then it will be quickly forgotten, and businesses will move on to brave new worlds of e-commerce, distributed computing, and other new technologies. And perhaps this WILL be the scenario for the largest, best-prepared organizations that really, truly did a good job with their Y2K remediation efforts. But even these companies may find that their plans are disrupted by the failures and Y2K problems of their suppliers and vendors. If nothing else, they may find that their contingency planning efforts, and their business-continuity plans, were incomplete, poorly tested, and badly deployed throughout the organization.
Even if every one of the Fortune-1000 companies is lucky enough to experience a BITR outcome for Y2K, there is a broad consensus that medium- and small-sized companies will have done a less-complete job of Y2K remediation, and will thus suffer a worse outcome. Similarly, even if one believes that the U.S. federal government has done a perfect job of remediating every one of its mission-critical systems, there is a broad consensus that the states and local governments will have far more problems. And even if the U.S., Canada, England, and Australia escape Y2K problems completely, there are many other countries that are likely to suffer severe disruptions.
My assertion is based on the premise that some, if not all, IT organizations will suffer Y2K-related problems that are substantially worse than the BITR level of "minor" glitches, but that it won't be bad enough to cause a complete shutdown and bankruptcy of the organization. The question is: how will senior management react if the mission-critical business IT systems are disrupted sufficiently that it causes significant productivity problems, lawsuits, shortfalls in revenues, and competitive disadvantage? What will they do if the problems persist throughout the entire year, so that they cannot be conveniently dismissed by an embarrassed CIO as a momentary aberration?
Some of this will depend on the assurances that senior management was given BEFORE the 1 Jan 2000 rollover; and some of it will depend on the opinions and reactions that have been forming during the past 2-3 years of Y2K remediation work. In at least a few of the organizations that I have visited, senior management is furious that their IT department has put them in a non-negotiable position of having to spend hundreds of millions of dollars to fix their computer systems. And CIO's have been furious at the discovery that there was no inventory of systems, no configuration management, and in some cases, no source code for the organization's mission-critical systems. And one must assume that in other organizations, senior management has been satisfied with the activities and accomplishments of IT; and perhaps they have accepted the notion that Y2K is an "act of God" that could not have been prevented or anticipated.
I believe that the overall situation will be another of the bell-curve distributions: at one end of the spectrum, we'll have companies that are so disgusted by the damage caused by Y2K that they'll simply outsource the entire IT operation. And at the other end of the spectrum, we'll have a few companies that are delighted with the outcome of Y2K. But the prevailing reaction, I believe, will be one of frustration and dissatisfaction with IT's performance, both before and after the Y2K rollover. And I believe this will lead to a senior executive backlash expressed in such terms as "Those IT cowboys almost drove us out of business. Never again! They may think they're creative, brilliant, and innovative -- but from now on, we're going to regulate, scrutinize, and standardize their activities so heavily that they'll never take us by surprise again."
The first consequence of this backlash, I believe, will be a ceremonial firing of the CIO and IT management perceived to be responsible for the problem. And the new managers who replace them will be fanatics in the area of quality assurance, best practices, methodologies, SEI-CMM assessments, and a host of other such disciplines and practices. Those espousing "good-enough" development practices, methodology-free RAD development strategies, and other popular approaches of the 1990s, will be banished to Siberia.
Another consequence of this backlash, I believe, will be a further delay in the approval of new development work in IT departments -- not because the new projects lack a business justification, but because senior management will insist that (a) all Y2K problems be rectified first, especially if they are causing major operational disruptions through the year 2000, and (b) a more formal development discipline be installed before the new projects are launched.
Paul Strassmann has escalated this "assertion" of mine to a much higher level: he argues that if Y2K is perceived (politically) to be a national "crisis" -- e.g., if it is held resopnsible for having caused major bankruptcies, stock-market collapses, and an overall economic recession/depression -- then it will lead to the same kind of government oversight and regulation that occurred after the 1929 stock market crash. It's interesting, for example, that the SEC has taken a leadership role in forcing publicly-traded companies to disclose a few wishy-washy facts about their Y2K status and readiness; Strassmann argues that if the economic impact of Y2K is bad enough, the SEC will insist on audited "technology statements" that represent the IT version of today's "financial statements." The notion of auditing such statements is likely to gain support if it's perceived that the "self-reported" Y2K readiness statements were largely inaccurate and self-serving.
It's interesting that the Meta Group is predicting a very different scenario from what I have described. I received an email message from a Computerworld reporter last week, who says that a recent Meta survey indicates that (a) a large percentage of SQA personnel have been transferred from their regular assignments to Y2K projects in the past year or two, (b) the Y2K projects are winding down, (c) the SQA people are being terminated, rather than being transferred back to their former assignments, and that (d) one must infer from this that IT departments have decided that they can do without the investment in SQA they had been making in previous years. If this is true, it would suggest that IT departments have decided that the "good-enough" software approach is acceptable. My belief is that the outcome of Y2K will eliminate this nascent trend.
If this assertion looks somewhat plausible, I can expand the discussion quite a bit. More work needs to be put into the explanation of why such a state of affairs might develop; and I can also expand on the discussion about the implications and consequences of the state of affairs.
-- Anonymous, October 11, 1999