As public awareness of the Y2000 problem increases, concern about its possible effects declines. According to USA Today/Gallup polls conducted in December 1998 and March 1999, 21% of the US population now expects major problems to result from Y2000; 38% expressed similar concerns in December. Curiously, the same two polls also show a trend toward a greater awareness of the problem. In December, 39% reported that they had seen, read, or heard "a great deal" about Y2000; 56% reported the same level of exposure in March.

Cutter Consortium's Chairman and Director of its Y2000 Advisory Service, Ed Yourdon, has recently raised a red flag in the midst of the flurry of optimistic Y2000 announcements:

IT practitioners have been preoccupied for the last several years fixing what the media refers to as the Y2K bug, which was not a bug at all (remember what a gigabyte of DASD cost in 1972? Try $6 million!). While we are merrily "IV and V-ing" code and creating contingency plans, some interesting things are going on that will make the years after the millennium very interesting.

Recently, I've observed yet another disturbing trend in the software industry. The various groups I work with exhibit considerable interest in requirements and coding, but the word "design" rarely comes up. I often ask seminar audiences how they do software design. The response is usually an awkward silence. Then someone hesitantly says, "We mostly write text descriptions of our designs," or "We all draw whatever kinds of pictures we feel like."

Most successful professionals have had one or more mentors during their career. They may not have realized these people were mentors, but they were being mentored nonetheless. They were being given guidance on important career decisions. They were taught how to handle new and perplexing problems, from tricks to debugging a deadlock to understanding how to terminate an employee. I can't possibly enumerate all of the help and guidance I've received from my mentors.

A project manager was working on assigning resources to an important project with a compressed schedule and, as is often the case, there were not enough available people with the required skills and experience. As she and I talked about various strategies to deal with the situation, I noticed two available people had not been considered, and I asked why.

Software projects require us to write documents. This is especially true on government and outsourced contracts, which often require developers to come up with requirements, design specifications, and/or maintenance documents. But software developers write software for a living, not documents. Developers are neither adept at, nor fond of, writing documents. This lack of skill and desire is a bad combination. Writing a decent document under these circumstances takes too much time.

I believe strongly that it is of utmost importance for a project team to have a thorough, complete project plan before deliverables are created. But time and again, I watch even experienced project managers eager to "make a mark" jump into deliverable-based work before a workplan, timeline, and estimate is developed and agreed to.