I've just uploaded the first draft of Chapter 9 of the "Humpty Dumpty" book. Feedback and comments welcome, as always.

I decided to start with a topic that I understand reasonably well, in order to get a better sense of how I would organize and present the information. Having done so, I'll start jumping around other chapters in the current version of the outline, and will probably save the most difficult topics (e.g., government/politics, and society/culture) to the end.

Ed

-- Ed Yourdon (HumptyDumptyY2K@yourdon.com), August 12, 1999

Answers

Big Dog,

Hmmm... interesting points. Yeah, if we do reach a level 7-9 "severe" Y2K crisis, the first few months of "fire-fighting" could stretch to a period of years. And anyone who has worked in a fire-fighting software maintenance environment knows that the rules tend to get thrown out the window while people desperately search for bugs and solutions to the bugs.

...and this means that our software assets might be in an even MORE chaotic state when/if we finally do reach an equilibrium, and find that we're fixing old bugs faster than new ones pop up.

Pretty depressing ... but definitely something I need to think about.

THanks for the insight!

Ed

-- Ed Yourdon (HumptyDumptyY2K@yourdon.com), August 13, 1999.

You touched on an area I thought would go into Chapter 17. That is to say the subject of backup for mission-critical systems. An aircraft manufacturer is required by the FAA to design in back up systems for those that are likely to fail and whose failure can cause the aircraft to crash. Can we say the same about critical systems in society such as electrical power, water utilities, etc?

-- Mikey2k (mikey2k@he.wont.eat.it), August 12, 1999.

I think there is a lesson here for you as a writer: this is your strong suit. I personally think you would do better writing a shorter book that focused intensely on chapter nine as its center and other things as radial spokes from that rather than cover the whole "world" with a broader brush. If you don't, heck, I may have to write such a book!

I will re-read this chapter in detail this weekend. Meanwhile, just a quick thought --

I have often posted my conviction that certification and regularion are a sure consequence of Y2K, no matter what, and still believe that. However, the greater the Y2K impacts, the more difficult will be that effort for three reasons:

1. All energy will be focused on cobbling together existing systems and writing critically needed new ones. We think no one has "time" NOW for careful spec, design, test, validation. ROFLMAO.

2. Governments will be too busy focusing on system survival issues to do much and will be nervous about disincenting the people they STILL rely on (hey, at least our industry will always be essential). See 1. above.

3. Consensus on what to do, how much to do will be difficult to obtain. See 1. and 2. above.

Point: for at least the first decade of the 21st century, we might have LESS, not more, IT regulation.

-- BigDog (BigDog@duffer.com), August 13, 1999.

Some random points:

- certification may be a natural reaction, but it won't help. Y2K is an architectural flaw, not simply a bug due to incompetance. Certification would not have eliminated this design tradeoff. And in general, certifying programmers to prevent bugs is like saying that licensing construction workers prevents ugly buildings from being built!

- In any case, you won't be talking about not being able to write code without a license. That would be like trying to regular all authors (maybe literally, if distributing code is a first amendment right.) More likely, we would see companies requiring certification as a prereq to hiring or contracting. Hiring uncertified programmers would be seen as a due diligence risk.

- If the no-warranty stands up in court (I've seen lawyers say it will, and it should -- it's clear enough), then legal responsibility will fall on the companies that bought the stuff, since they certainly had the option of insisting on guarantees for code they bought.

- a better answer is to require that mission critical applications be independently audited. For critical systems anyway (on the scale of an SAP-type system), a customer should be able to see a complete test suite and get some guarantees about bugs. Same for embedded systems. But actually, I think that's probably the case now. If GM had a car fail due to software in the engine control system, they would certainly be liable. Contracts that I've done usually delay the last installment of payment until the customer is happy. After acceptance, it's their problem. The no-warranty is just for desktop stuff, where the margins are too low to justify the expense.

- In any case, the certification requirement should be up to the customer, not a regulation applying to all programmers. Do that, and most programming will move offshore. And for some things, like games, or simple apps, it's just not worth it. A standard laying out what critical system IV&V should look like would be useful. Then a typical software contract could reference the standard. And even some of the more expensive desktop software could be sold with the promise that it was audited.

- if we're beyond a 3, I do expect an irrational reaction of some kind. Like certification, or clamping down on Internet content, or banning good cryptography, or Microsoft antitrust. Y2K has no bearing on those arguments, but the loss of status by the software industry will mean the industry will get its way less often. We won't be the darlings of the U.S. economy any more. And even if things are legal now, there's no protection against retroactive changes in the law. Look at the tobacco and gun industries. They met the letter of the law, but once they got unpopular enough, the legal system found a way to get at them.

- Silicon valley could get unpleasant. A long-term drop in the stock market will dry up the venture funding. Many of the startups will close, with no revenues and no prospect of future growth. A general slowdown will shrink the market for computers and software. The programmers sitting on overpriced housing or newly unemployed will be very hungry for work. The job hopping will slow way down. So look for a horrible contracting market, dropping salaries, and way too much competition for what's left.

-- Michael Goodfellow (mgoodfel@best.com), August 15, 1999.

You are forgetting about the real reaction. Public outcry and government draft of computer programmers to fix systems no matter what. Employment will not be a problem for programmers. They will be working, no doubts about that. The working conditions may be tense, though.

-- snatch up (programmers@ball.chains), August 15, 1999.

I don't think our government is deranged enough to try to fix systems with slave labor. They would have to worry about sabotage. However, there will be fixup work to go around. I don't expect to be unemployed in 2000, but in 2001....

-- Michael Goodfellow (mgoodfel@best.com), August 15, 1999.

This chapter seems to be going two directions at once. After a good discussion of process and personnel certification, it branches off into a "what if" scenario for home computers. This is more the flavor of TB2K than a discussion of options for what will be a current situation by the time most readers get hold of the book.

As to certification, I agree that something will be done, simply because something needs to be done. Individual software developers for the most part haven't seen the light. Indeed, most developers see certification as anathema. What they're afraid of, I don't know.

I've certified under ICCP, and feel that their exams could be improved by emphasizing questions on the lifecycle process and the specifics of design, requirements tracing, and testing. Deleting the questions about tape blocking factors and other ancient memories could only improve them.

One of the arguments against certification exams is the impossibility of keeping them current, and tape blocking factor questions certainly play into that argument. However, most board exams for the medical, legal, accounting, and engineering professions have a mix of current technical questions and a series of questions related to the processes they use. It is possible to keep a certification exam current for the profession; happens all the time except for software, it seems.

Vendor-specific certification seems to be taking hold at the individual level, and process-specific certification (CMM, ISO-9000) seem to be taking hold at the organizational level. What I would hope is that individuals start being certified on process as well as tools. Perhaps this is the way we will start migrating toward a more professional approach overall.

-- John Zoltai (jtz@lanl.gov), August 17, 1999.

Ed - Assuming you would like editing as well as editorial help...

Chapter 9 prints on 13 pages for me.

On page two, paragraph begins "With rare exceptions..." Last sentance seems to be missing a word. Systems? Software?

On page 9, paragraph begins "One could argue..." First sentance is missing a word between "highly" and "institutions". Important? Critical?

P9, "Whatever laws..." Sentance five should be "left to their own devices" not "down devices".

P9, "What are the nations..." I think the third sentance should start "We discuss..." It's only future tense now as you're writing the book, but since this is Chapter 9, they may have already read that part.

P11, "Learning to live with 'kludgy'..." I'm pretty sure the hero of the Star Wars series was Han Solo.

Editorial Comment: I thoroughly enjoy your writing. (I like your fiction too. Why don't you drop out for a year in New Mexico, and write the great American novel?)

I've not read "Decline and Fall", but I agree with the gist of what it says. There is very little craftsmanship left in programming. In the olden days, when you just had to know JCL and COBOL, there was time to develop the craft. And the programs DID last, and were durable. Now we make software the way we make running shoes and kitchen chairs...cheaply, with an eye to disposability. Everything's throwaway. And I'm as disappointed with my wobbly kitchen chair as I am with FAX programs too stupid to parse out the non-numeric characters.

-- Jim Smith (JDSmith1@hotmail.com), August 19, 1999.

Ah, you can always tell an old COBOL programmer; you don't have to be able to spell, just consistent.

Change all "sentance" to "sentence".

-- Jim Smith (JDSmith1@Hotmail.com), August 19, 1999.

From: Y2K, ` la Carte by Dancr (pic), near Monterey, California

link to chapter 9

-- Dancr (addy.available@my.webpage), October 08, 1999.

From: Y2K, ` la Carte by Dancr (pic), near Monterey, California

"Thus, if you think that the Y2K problem is unique, or that software developers have been taken by surprise when their [MISSING WORD] began to misbehave, think again."

The blame game section fails to mention government as a target of blame. During the Nixon administration, someone in the DoD foiled an attempt to get programmers to use a four-digit date, on the basis that the Vietnam War was more urgent. This set the two-year standard in stone for any companies that had any hopes of some day serving as military contractors.

On another thread about chapter 9 I write against certification for programmers. Certification would not help in avoiding Y2K-like problems. It would, in fact, make such problems more likely and worse. To the extent that programmers are trained using a single standard, if there is any flaw in that standard, it will be multiplied across all software projects.

The certification process in medicine has not succeeded in weeding out inferior practitioners. What the process does is select for doctors who are willing to listen to pronouncements from on high (AMA), and obey without question. Thus, we end up with a nation full of doctors who unquestioningly advocate vaccinations despite substantial evidence that administering them nationwide could lead to a tragic Y2K-like health catastrophe. It should be no surprise that the giving of vaccinations is immensely profitable.

"One could argue that such highly [MISSING WORD] institutions as banks, or the FAA, or the electrical utilities are so visible, and so vulnerable to repercussions if they encounter severe Y2K problems that they would never dream of exaggerating the success of their Y2K readiness efforts."

I do think that it is reasonable to require those companies who have used "windowing" as their solution to their Y2K problems, to come under some kind of supervision to ensure that their code will be properly remedied in a timely fashion. These companies should be required to submit an assessment report detailing what systems are involved, time estimates for remediation, and a schedule of work to be done, showing how many programmer-years the work will take. This schedule should allow completion well ahead of the expiration of the time window, with a generous period for testing. We should not be expected to rely upon self-reports to evaluate their progress. This is the only software regulation that I see as being worthwhile.

Would it be possible to serve both as a strong voice against certification, and also as a voice helping to direct such certification efforts so that they will be as harmless as possible? Assuming that certification is inevitable (and I'm not sure that this is true), what form would we like to see it take? I, for one, disbelieve that a four-year college degree is even a marginally useful measure of programming competence.

-- Dancr (addy.available@my.webpage), October 08, 1999.