Summertime is traditionally the period when I catch up with the trade magazines and computer journals that pile up in the office while I'm gone. While skimming through several back issues of *Information Week*, I came across an article discussing the top business issues of today's CEOs. Interestingly, IT and management of corporate data was at the top of the list, followed by "impact of new technology," and business reengineering.

An astonishing 85% of companies recently surveyed admit that they have underestimated their year-2000 costs; only 3% responded that their Y2000 costs are "on target."

You've heard the phrase; you know what it means. You agree that it's a bad idea, and so does your boss, as well as his or her boss. Yet the practice continues to flourish, especially in large organizations -- and particularly on large, complex, highly visible, mission- critical IT projects.

An IT manager friend of mine tells me that one of the most interesting questions he asks when interviewing programmers and software engineers is: "Tell me three or four of the most recent computer books you've read, and what you thought of them." And if he's feeling ornery, he follows that with another question: "Tell me a few recent non-computer books you've read, and what you thought of them."

In the Y2000 field, there is an ongoing debate about the ethical responsibility of IT professionals to resist the temptation to "bug out" and head for the hills. Strong suggestions are being made that good programmers will remain loyal to society, and to their profession, by staying on the job to fix Y2000 bugs right up until midnight on 31 December 1999 -- and beyond.

A couple of weeks ago, I commented on the strategies for recruiting additional software engineers in the face of personnel shortages. Since then, I've seen three or four indications that another strategy is gaining popularity in several parts of the country: hiring and training high-school students as "paraprogrammers." I use the term here in the same sense as "paralegal" or "paranurse," and I think it's just as relevant and valuable.

As we all know by now, you cannot manage what you do not measure, which has been taken to its extreme in the TQM movement. But what should be the metrics of IS? Should it be input or output, or output per input? Lines of code per labor hour, or ROI perhaps.

The notion of a "post mortem" is familiar to most software developers and project managers: at the end of an application development project, a report is written to document the good, the bad, and the ugly experiences, so that future projects can learn and improve. In theory, it's a useful concept; in practice, it's largely ignored.

I've just returned from a week in Rome, where I presented a seminar on application development for the Internet. One of the most frequent questions I received was, "What about the future of Java?" Italians, Europeans, and Americans have been hearing a lot lately about the uncertainty surrounding Java's future. Is Sun struggling? Is Javasoft reorganizing, and what does that bode for its future? Will Microsoft prevail in its lawsuit, and thus have the freedom to develop and market its own bastardized version of the language?

Have you noticed that things have changed when you interview prospective software engineers? There was a time when you had all the power, and the candidates trembled and quaked as they waited to see if you were interested in their humble skills. You interrogated them mercilessly, and then you told them they would have to come back for a second, third, and fourth interview. Many of the candidates concluded that getting a job offer was as much a test of endurance as one of demonstrating technical skills.

It's a familiar scenario: you've just been assigned to manage a mission-critical IT project, and you've been told that you've got a schedule of six months, a staff of five people, and a budget of $250,000. But with a little investigation and estimating work, you've concluded that at the very least, it will take 12 months, 10 people, and $1 million. You try to negotiate a more reasonable set of project parameters, but you're told that the deadline is fixed, that no additional people can be hired, and that money is tight.

Well, it finally happened: Microsoft's game of "hardball" has resulted in a lawsuit from the Justice Department and from the attorneys general of 20 states. Assuming that there's no last-minute out-of-court settlement (which briefly appeared to be happening last weekend), this is a case that could drag on for years. And, conceivably, it could have as large an impact as the anti-trust lawsuit against IBM in the 1960s and against AT&T in the 1980s.

As reuse programs gain steam and application development units utilize increasing proportions of reusable components, their total productivity indexes (PIs) will increase. If they don't increase, something is wrong with the reuse program -- it is a signal to look into a problem. That is one of the functions of metrics. "Working PIs," reflecting an application unit's effectiveness in developing new code, serve the same function as management metrics have all along.