Remember this the next time someone compares software construction to building a house: "Well, what I've learned from my first large construction project is that this is hogwash. The building industry doesn't know how to do anything on schedule or on budget, either."

Joshua Allen has an interesting post on the changing balance between development and testing resources, at least at Microsoft. While the general claim that the advent of managed code has made developers so much more productive that the testers are now overwhelmed is pretty significant, the really interesting quote is in the third paragraph: "there is always the possibility that the ever-increasing test expenditures will not coincide with a reduction in the number or severity of high-profile security and quality incidents". To me, that suggests that the skill set for testers is changing. Now I understand that it's typical for MS to hire more development oriented types as testers, but in every company I've worked for, testers tend not to have significant programming experience and are on the whole less technical than the programmers. So testers tend to concentrace on UI and HCI types of tasks and not so much on security analysis. I think that testing for security would require a technical and likely a programming background, so I would expect that companies that are concerned about security would not simply reduce programming headcount, but would end up moving programming resources from development to testing. In the end, assuming that companies manage their people efficiently, I expect that the increased programmer productivity would be a wash, rather than an opportunity to reduce headcount.