Richard Caetano at Stronglytyped is bemoaning what college campuses are already showing – a declining interest and enrollment in Software and Computer Science. Richard attributes the cause to Microsoft commoditizing software development; but the simple fact of the matter is that all ISVs have been moving towards simplifying and easing coding/programming for a long time. One only has to look at a long history starting in the early 1960s template driven software, the 1970s and 1980s CASE-Computer Aided Software Engineering, and the current MDA-Model Driven Architectures to see just the surface phenomena.
Rather I think Richard catches some of the other real culprits. Part of the problem is due to the recessionary downturns effect on development. Another is the maturing of the IT industry (we are in the late adopters stage of the PC market). Finally there is the availability of huge groups of overseas developers who are now Internet accessible and well trained in India, China and Central Europe. As well, developers have been victims of what I call the “Shamegment of Change” problem.
It still astonishes me that just 8-10 years ago the Standish Group and Capers Jones(see his book Applied Software Development) were reporting year after year of 40-60% complete IT project failure rates in the IT business. And the Standish Group still reports that nearly 50% of current IT projects come in either off spec, off budget and/or off delivery dates. It has been a shame and a sham of management.
Management of IT information processing projects is first and foremost an exercise in change management – old work processes, reward sytems, and cubby holes of prestige and importance are being changed. The effects of IT change can be quite broad across an organization affecting many people in many ways. When peoples work, prestige, and sense of belonging get shifted in ways perceived to be arbitrary they too can act arbitrarily. And MBA and IT schools and IT literature have barely touched upon this topic. See the length of IT project management books by Yourdon, McConnell, Brown and others in which change management is just barely covered but never addressed in a concerted manner.
Even the latest development methologies such as Agile Modeling and Extreme Programming only hint at the problem. They acknowledge the need to accomodate and change system specs to meet users needs as much as possible and also insisting on getting all stakeholders involved; however the there is no deeper analysis – like a go-nogo decision based on an assessment of how much change the stakeholders are prepared to accept or management is prepared to fight for. So the fundamental management problem is this – what if those stakeholders are inwardly opposed but outwardly nodding their heads in proforma agreement ? In effect, all parts of organizations have seen themselves downsized, commoditized, automated, outsourced and otherwise shape-shifted out of jobs by IT projects. So why let the wolves in without some subtle sabotage ?
Now as Harvard Business Magazine so dutifully notes – IT is becoming more commodity driven and its innovations not nearly as dominant and as important as they were just 5 years ago ; thus the same IT automation, outsourcing and commoditizing trends are now being applied to IT projects and their software developers. And for this and other reasons computer enrollment has been declining for the past 3-5 years in colleges – and so, in effect, the IT market is already adjusting to a less pivotal role.
My argument is that if IT developers had been more Agile and top management more change management oriented (see the Price Waterhouse book on Change Management); this transition would be less abrupt and contentious and a lot smoother. But it appears IT denizens will have to absorb some IT-like medicines.