I've been looking for ways to help Microsoft's programmers get focused on security. Not just because the company last week announced yet another batch of security holes in its products - including a vulnerability in Internet Explorer that Microsoft called "critical" - but because I figured something that works for Microsoft will probably work for programmers in corporate IT shops, too.
Unfortunately, it looks like Microsoft's corporate commitment to security ?ber alles won't be enough. Even sending 7,000 programmers to class for a quick security training refresher isn't likely to do it.
That's because programmers have a hard time changing. A really hard time.
Watts Humphrey found that out the hard way. Humphrey is the guy behind the Capability Maturity Model - as in the "CMM Level 5" that software development outsourcers like to brag about. CMM, which Humphrey developed at Carnegie Mellon University's Software Engineering Institute, is both a way of gauging how good an organization's software development process is (from Level 1 up to Level 5) and an approach to making it better.
But before CMM, Humphrey spent 27 years at IBM, where for a time, he managed all IBM commercial software development and banged his head against the problems of improving quality and on-time delivery at what was then the world's biggest software vendor.
According to Humphrey's own account in a series of 1998 articles for the software journal Crosstalk, when he took on IBM's thousands of programmers, every programmer was heads-down and focused just on coding and testing - and every project was in trouble and behind schedule.
Any similarity to Microsoft's quality and delivery troubles is no coincidence.
Humphrey quickly discovered that just telling programmers and managers to use better practices, or even telling them that better practices were now the No. 1 priority, wasn't enough - because the better practices weren't used.
That problem wasn't just at IBM. Here's Humphrey talking about a later effort to improve practices: "One manager even told his people that it was more important for them to use these methods than to meet their project schedules. The engineers all said they would do so, but none of them did."
And why not? Humphrey finally figured it out: "Engineers only believe new methods work after they use them and see the results, but they will not use the methods until they believe they work." In other words, reminders aren't enough. Training isn't enough. Even sincere and enthusiastic management support isn't enough. Programmers believe they know best how to do their work. They don't believe other approaches will work until they've used them successfully. And that usually means they must be forced to use them.
At IBM, it took an absolute management decree that no software project would continue until the new methods were actually being used. In later efforts at the Software Engineering Institute, Humphrey found he actually had to pull teams of programmers off their day- to-day jobs and put them through a rigorous hands-on training course to get them to change their ways.
That's what Microsoft is facing if the company really means to improve security in its products. It will take more than a day of classes for each programmer, more than a serious management commitment to its Trustworthy Computing initiative. It will require deep, well-designed training and rigorous, even radical changes in how every software project is managed.
The good news for Microsoft is that even if the cost of these changes is as much as $100,000 per programmer, the company has money in the bank to pay it. It'll be tough, but if Microsoft is willing to pay the price, it can be done.
The bad news? The rest of us don't have that kind of money lying around this year - and we'll have to look for a cheaper way to deal with our software security problems.
Frank Hayes, Computerworld's senior news columnist, has covered IT for more than 20 years. Contact him at frank_hayes@computerworld.com.