While the economic slowdown coming our way from the other side of the Atlantic may yet overtake these estimates (although only telecoms professionals seem to be hit so far), few analysts believe the downturn will be deep or long.
So after some corrections, IT will continue to be a growth industry, particularly in the e-business area, trying to suck in more people. But since a 30% growth in available staff simply isn't going to happen, IT directors need to do so some lateral thinking if their departments are not going to be overwhelmed by work.
A thoughtful article by John McDermid in the BCS's Computer Bulletin caught my eye with many observations about how improved productivity could be a way to solve the problem. The key lies not in getting people to work harder, but in a smarter way.
Last month I attended a European conference on formal methods for improved productivity. Formal methods are abstract mathematical techniques for writing software. With an austere use of terse mathematics, and names like Z, VDM, CSP, CCS and Lotos, these methods have yet to reach a mass audience, despite now being taught on most undergraduate computing courses.
The key to formal techniques is 'abstraction': finding a way to describe a computer system that avoids extraneous detail allows you to reason how the system will behave before you have built it.
This is tremendously valuable for critical or high-integrity applications. Such methods are routinely used in railway signalling, some security applications and chip design (mistakes in silicon are phenomenally expensive to correct).
The theme of productivity rather than high-integrity systems gave the conference a novelty, and it did not disappoint. It seems that the best software developers are just starting to conclude these may help in delivering quality software on time and within budget. Though they require fairly high-level mathematical skills, formal methods are accessible to most programmers and systems analysts.
The problem with software is that it's too easy to start making it before you've thought hard enough about what it is you want to make. It's even easy to make something that looks like the product, complete with buttons and menus, long before you've worked out exactly what should be going on behind the scenes. All too often, that leads to a promise to deliver the finished article by an unfeasible date.
Time to market is king, and only a brave software engineer tells their manager they'll be spending the first half of their project talking to clients, thinking, specifying and designing, rather than producing those all-important lines of code, screens or Web pages. Yet, very often this is precisely the way to ensure that the final product really performs. Faults introduced at the requirements/specification phase are phenomenally expensive to fix if they are not discovered until late in the project.
It's depressing to see how people have come to expect software to fail. It comes as no surprise to hear of enormous projects being cancelled because they've lost their way. A fortune could be saved, and people profitably redeployed, if only we were better at building the right software, and building it right.
Formal methods are part of the solution. The real key is in getting people to think hard about software before building it, and giving them the intellectual tools to design it right.
Andrew Martin is a lecturer in software engineering at Oxford University's computing lab