This particular essay has been sitting as a draft on my laptop for some time. I’ve been intrigued lately by the bigger issues facing the IT market, and especially of the people who work in it. The news of late seems to be ominously similar in tone no matter where you go, that even in the face of softening employment elsewhere companies can’t fill programmers fast enough. I don’t think this is peculiar to this particular moment, but may in fact shadow a significant shift in the relationship of the IT workforce to the companies who employs it. My apologies for the length, but there’s a lot to cover …
An interesting paradox is occurring right now in the IT market, one that I predicted back in 2002 when jobs for programmers were as scarce as new IPOs about then. In a nutshell, even as the general economy is beginning to suffer from significant doldrums, the demand for skilled IT professionals has seldom been higher … and many companies are having to shelve new production because they can’t find the programmers to build their applications … globally. From the United States and Canada to England, Germany, India, China, Japan, Australia … there just don’t seem to be enough skilled programmers to fill more than about fifty percent of all IT-related jobs.
A number of reasons for this have been pushed forward for this, each with a certain degree of merit. Demographics certainly is a factor - the typical image of the programmer - a male in his mid-twenties or early thirties, usually with at least a four year college education, factors into every recruiter’s mind when they are hiring, usually for good reason. Such programmers are typically single (and hence don’t mind working 12 and 14 hour days), don’t necessarily know their real full worth, are fairly easily malleable, and are often most adept with the hottest technology of the day. The older you get, the less BS you’re willing to put up with, the higher your rates, and typically the greater your expectations that you will be involved at a management level, none of which is attractive to a company that’s hoping to get the most for the least.
Yet the workforce is getting older. The boomer generation’s birth-rate peaked in 1955, which puts the echo boomers - their children, hitting their peak back in 1980. The average age of the Echo generation is now 27 years old, or, put another (and rather disturbing way), the demographic trends indicate a fairly significant drop-off of “prime” technical talent from this year on, with the next major bump not likely to occur until nearly 2020 (a considerably smaller bump, as it’s the peak of the smaller GenX population’s children).
The market itself also shoulders a fair amount of blame on this. Stock options are a form of corporate roulette. For those early enough into the game, stock options proved to be incredibly powerful, both because the likelihood of a company increasing in valuation several thousand-fold was very real and because, from the standpoint of many companies, stock-options meant that rather than the company actually bearing the cost of paying for good talent, the company was able to push that cost to the stock market; in essence, the stock speculators became the real owners of that talent. I think that this head the effect of salaries being undervalued significantly in the market for good IT professionals, most of whom either figured or were coerced into believing that their real compensation would come when the company went public.
The tech market collapse in the early part of this decade gave the lie to that. Many inventive people ended up giving up their key marketable products to companies that paid them poorly then dismissed them when the market was no longer there to keep the float going. Now there’s a funny thing about both programmers and engineers: they are not stupid. They may appear a little naive sometimes, somewhat disconnected from the rest of the world, but that has more to do with the fact that they are thinking about considerably more abstract issues than just winning the latest account or who was booted off American Idol or whether this tie goes with that shirt. Programmers don’t like being lied to, and once their trust is lost, its hard to get it back, because the effect of such trust is that they HAVE to deal with the real world, something they generally don’t like to do.
This has had several effects. Many people with solid IT skills went into other areas, returning to school in great numbers during the tech winter to retrain themselves as doctors, lawyers, managers or teachers, among other professions, or they left pure IT to go into biotech. They discouraged young college students from entering the field, meaning that many people that may have trained in IT have instead gone elsewhere. The ones that had made a fair amount of money during the boom became entrepeneurs themselves, often starting tech companies that in turn absorbed the available talent even faster. Others followed the money into financial services or real estate, and while some may be contemplating a return to IT as that market has softened its unlikely that there will be a mass influx of older but wiser programmers.
The problem with IT skills, you see, is that they degrade quickly. If you are out of the marketplace for a year, you face a challenge getting back up to speed in your field. If you are out of the marketplace for more than two years, then the barriers to re-entry are almost insurmountable (a point I’ll come back to in a bit). This means that for many people, once you leave IT for any significant duration, you’re effectively out of it completely, at least as far as programming goes.
Moreover, a fairly significant number of developers who entered the field in the late 1990s came from the legacy field in response to Y2K - in other words, they were already semi-retired from programming to begin with, and were drawn back because their particular languages - COBOL, RPG, etc., were in significant demand. This helped pad retirement accounts, but again with the tech winter, most of these people have moved back out of active programming, this time likely for good.
The upshot of this is that there is a continuing drain upon the IT field due to programmers moving on or moving out, coupled with an impending drop due to raw demographics coupled with an overall negative image being painted of the IT field at the college level that are whittling away all but the most dedicated developers before they even graduate.
Educational funding and priorities have also played a part in this process, unfortunately. University level curricula take three to eight years to implement, typically, which means that they are usually quite adept at teaching what was contemporary half a decade before. Thus, it’s likely that courses in Ruby or AJAX will likely not appear in the typical university catalog until 2009 at the earliest. The community colleges are generally more nimble, though they too have a lag time that they have to fight.
While this can be seen as a necessary brake on “fad languages”, the reality is that from the time that a person enters college, they will be looking at seven to eight years before they are even at a journeyman programmer level, of which nearly half that ends up being borne as “on-the-job” training to companies. Those same companies, of course, see such OTJ training as a drain on their internal resources, and usually end up outsourcing that training to certification companies (often with the programmer picking up the tab for that training). Moreover, such companies also fear (with some justification) that once an employee receives an adequate amount of technical training, they will take those new skills to an employer willing to pay a higher wage.
All this has, of course, occurred against the backdrop of the US government shifting its spending priorities from education and training to fighting wars on multiple fronts. This has meant that in general colleges have been receiving less funding for technical education programs, except in the context of military training, which in turn means that even among a shrinking demographic, the people most likely to get university or even college training are those who can afford increasingly expensive schools with fewer grants and now increasingly expensive loans as mortgage rate increases dry up credit liquidity.
Choosing a career is making an investment, and as the number of tech IPOs decrease relative to the overall stock market, as the amount of open source code reduces the market niches for software companies, as software as a service kicks into high gear, the opportunities for the “big kill” became increasingly rare. This doesn’t mean that it won’t continue to happen, mind you, but what happens is that programming is rapidly becoming yet another one of the “Lottery Professions” - underpaid for the work and time invested in 99.9% of the case, but a multibillion dollar lotto winner in that remaining tenth of one percent.
Such lottery professions aren’t limited to software, of course. Any creative profession is beginning to look like this - if you are already well connected, have the means to be at the right place at the right time, or just happen to accidentally stumble upon the ever shifting public zeitgeist, you do well. Otherwise, its not worth the time. Of course, even this tends to work against employers - given the danger of being too far from the forefront of the tech revolution (where you’re able to buy more lotto tickets, if you will), programmers tend to instinctively shy away from older tech, even if it appears more lucrative at first, because the opportunities for the “big breaks” are fewer and farther between.
What this means to many companies is simple - the compensation and training costs for technical employees is not a drain on the coffers but an investment to keep them with the company. In one company I saw, one lynchpin employee - a senior architect - left the company because they had both cut pay and dramatically cut back on training in a “cost-cutting measure”. His departure led to the departure of nearly a dozen other programmers within the next six weeks (they saw the handwriting on the wall) which in turn meant the company lost several multimillion dollar contracts because they didn’t have the staff to bid for them. Many other companies that decimated their engineering and technical staff during the tech recession (often for no reason other than everyone else was doing it) have since discovered that they can’t get back even to half of their pre-2000 levels in IT and the people they are hiring are considerably less seasoned.
Of course, there’s always outsourcing … or is there? The same demographic trends that are hitting the US are hitting globally - and indeed, the US is probable safer here. This means that many countries are now competing for the same IT talent that previously was supplying the US with IT workers during the 1990s. Moreover, many of these places have brought back the wealth from those lucrative contracts and reinvested at home in order to build up their own domestic IT infrastructure, because of the demand for it there. Thus, the number of people available to outsource has been dropping pretty dramatically as well. Add into this the fact that the US dollar has fallen in value by anywhere from 10% to 30% in the last decade against most currencies in the world, and the cost benefits to outsourcing have quickly disappeared.
The same trend is occurring here in Canada, of course, though on the other side - its become increasingly difficult for Canadian software shops, production studios or the like to compete, because they can’t hire the talent, the talent they can hire is consequently paid considerably more, and the rising Loonie (up more than 25% in the last three years) reduces the cost advantage of going to Canada in the first place.
I personally believe that the days of cheap IT labor are behind us for several years to come at a minimum. In the short run, this is probably going to be a good time to be in IT if you’re a programmer. In the long run its likely the herald that the “software age” has reached a major transition point. Companies are already beginning to scale back IT projects because they can’t get enough developers in house, and their traditionally suppliers of talent, IT body shops, are ironically in a great deal of trouble.
The IT body shops of the late 90s did quite well in the dot-com rush because they could hire people cheaply and apply a significant markup, most of which was pure profit, largely because those programmers were fairly young, inexperienced, and eager to break into the market. During the dot-com bust, they had more people on their rosters than they could find work for, and while things were lean even for them, they tended to be very dismissive of IT people. Now, while they’re getting significant bounties for finding talent, the number of people they have on the bench, the ones that earn them the bulk of their income, is leaner than its ever been, and most even semi-experienced programmers recognize that they will do better to go through the companies themselves rather than letting the body shops agent them.
While the short term looks good for developers as a consequence, the longer term benefits for the industry overall is considerably more unsettled. Tech jobs in general are quite attractive to most politicians - they pay well (and consequently can be taxed well), they tend to attract a core of intelligent people who often participate disproportionately in the cultural life of their community, tech jobs are generally “green” in that they require comparatively little polluting infrastructure to sustain, and they tend to have a comparatively light footprint in terms of crime, drug abuse, and other societal “ills” compared to other groups.
Yet these jobs are also in danger of disappearing - projects unfulfilled get canceled and new projects can’t find the people to staff them, the growing base of services oriented software (and open source software) tends to fulfill the “good enough” needs of many who need software services, software developers end up working remotely as the technology has improved, meaning that it becomes more difficult to build that “critical mass” of developers that have long defined places like Seattle, Boston or San Francisco. I don’t think that we’ll have another market collapse similar to 2001-2004 (at least not in the tech sector); rather there is going to be a long, slow attrition, which will push IT managers to focus on software that is better able to adapt to business conditions and thus require fewer people to maintain.
As economic conditions improved in 2005, many companies started shifting their resources away from consultants (and service shops) and towards building up in-house staffs. However, the cost of maintaining that staff will continue to climb, and ultimately, especially as the US economy tilts into recession, its likely that such staff positions will be phased out in favor of near-source vendors for all but the most core maintenance functions. I don’t see this necessarily impacting salaries or job availability significantly for the developer, it just shifts which company they work for (and likely increases dramatically the ability for more senior developers to run their own companies or consultancies).
In other words, the long term trend for programmers is towards becoming consultants or joining small (up to maybe twenty five or so) specialty shops, and for those programmers to consequently shift away from being generalists to being specialists in a particular domain (in other words, their work relationships begins to look a lot more like that of doctors or lawyers than it does of tradesmen and women). Even in large software development companies (such as Microsoft, Sun, Google, or IBM) this shift is reshaping the way that such developers interact with companies - moving towards small, self-contained units that have a high degree of autonomy and where the individual members of those units are as likely to be working remotely as commuting in daily to the corporate headquarters (put another way, the campus model is dying, to be replaced by satellite campuses and telecommutes).
Gridlock and explosive housing prices factor into this as well - you may be able to make $150K a year in San Francisco as a developer, but kick in taxes, high gas and food prices, absurd housing prices and time lost due to commuting (not to mention the stress on yourself, your family, and your car), and the amount at the end of the month doesn’t look anywhere near as attractive as it might have otherwise.
Offshore development shops (where offshore is defined as being where the labor is cheapest), so indispensable to the corporate bottom line in the 1990s, are now becoming far less attractive as the cost of managing those resources rise and the competitive pressures on these same outsource agents force them to raise their own rates. At the same time, most developers in the IT field have adapted to working remotely, and it is the rare programmer who doesn’t have projects coming from outside their driving range. This is not as advantageous to business, but after nearly three decades of being in a position where they could dominate the labor/business relationship, demographics and technology are now both shifting that power to give programmers much more say in how they work.
This is the direction of the future. By 2010, qualifications for a project manager will include the ability to coordinate programmers from all over the world and the compensation model will evolve into a fixed-fee plus royalty basis (perhaps with a stake in the project as a side bet) rather than a per-hour basis, since the latter ultimately requires someone with a clock being able to track individual workers, difficult enough in a closed environment and impossible in an open, distributed one. The expectations on the developer will be that the they will become responsible for the purchase of their own equipment (most prefer that anyway, as a contract gone sour isn’t going to leave them without a computer when they most need it), pension plans, health care and so forth. There’s a business there for someone who can supply at least some of this, but that business needs to recognize that programmers are getting tired of the agent’s 15-30% take on their salaries for the “benefit” of providing some tax bookkeeping.
While it is unlikely that programmers will ever formally join “unions”, already networks are emerging that give those programmers nearly the same thing - information. A developer’s stock in trade is information, and as those networks (such as LinkedIn) strengthen, programmers will be able to tell whether a company is negotiating in good faith, will be able to determine what constitutes an appropriate compensation package, and will be able to warn away others from bad situations. Unions were competitive in the 1950s and 60s because companies had to negotiate with all of the members through their proxies, with failure to do so resulting in a strike or work-slowdown. I see the more informal networks of today as serving much the same purpose, but doing so without empowering yet another hierarchy at the expense of its members - having one’s company criticized among the very circle of developers that you are hoping to hire can prove a powerful incentive to play fairly.
Finally, a disclaimer - this is all a guess, based upon what I’m seeing and hearing from others in the industry. The IT field has long had the distinction of being a profession where the normal rules don’t apply, but demographics and technology both are trending towards what was discussed here, and in the absence of some ground-breaking revolution, I see developers moving into the catbird seat for some time to come.
Kurt Cagle is an author, consultant, and information architect specializing in XML and web technologies, and is the webmaster for XForms.org. He lives in Victoria, British Columbia, and can be reached at kurt.cagle@gmail.com.


At least we have finally entered the golden age of drag and drop programming which shifts the talent burden from bit-twiddlery to requirements analysis and effective UI design. With the new generation of application-specific frameworks (the layer ABOVE say .Net), we'll have to invent a new term because this isn't programming as much as it is component assembly and "script kiddie" seems unkind.
Does that change the economic picture? It means tool and license costs figure more in those projects that don't rely on open source, that mixed open and closed source systems (say ASP and PostGreSQL) are a bigger part of the mix, and that programming as a profession becomes even more of a tradecraft job with less status and possibly less women in the trade.
It also means being multilingual at least to the ability to work well in a shop where accents and skills cause every third word to be lost, and it means increased emphasis on the documentation process.
Somehow we get through these crunching changes but it is ever more evident that tradecraft level programming will become a supporting skill that many professions will require in addition to the principal skill set. The number of to-the-metal programmers can wax and wane and that will slow down the framework churn (do we need another word processor?) which might be a good thing.
Very good read. A little bit of over-generalization of developers, but all-in-all, this does address many of the issues that exist out there.
More importantly, however, is that the landscape for Network Engineers, Database Administrators and Systems Administrators is even more tight than for Developers, and these folks represent a critical part of the IT chain as well...
It's a good time to be in IT, and many of the organizations that have resorted to off-shoring simply for cost reasons will find that the costs have been rearranged, not eliminated.
ASB,
I'm familiar with the developer landscape, somewhat less so for the administrative side of things, though I would agree with you that if anything this sector is likely to be even more squeezed than the dev side will be. IT admins tend to be as much as a decade older, and usually have received considerable advanced training. Unlike the developer workforce, IT admins are much closer to retirement, and if the age of offshoring has affected developers, it has also meant that many organizations have chosen to have only one or at best two admins in a given slot, making them vulnerable to both retirement and poaching.
I've also wondered more than once whether the graphical approach that Microsoft has taken in its GUI admin tools may be backfiring. Such tools make it easier to administer sites, but at the cost typically of less understanding of what is in fact happening in the background. Admin positions especially tend to be trained on the job, and I suspect that this lack of understanding will propagate to the newer admins as a consequence.
-- Kurt
Len,
You know, it's funny, but I've been waiting for drag and drop programming for years, expecting with each subsequent generation of dev tools that we'll finally drop below the threshold at which programming becomes easy enough for the non-programmer.
Curiously, it never quite seems to come. JavaScript or Ruby are arguably simpler than Java or C++, but they're being used increasingly to handle distributed computing where the efficiencies of formal type declaration get lost and the costs of such become quite real. Indeed, what I find intriguing is that JavaScript as a language is evolving into something much more evocative of Lisp or Scheme than the fairly basic language it started out from.
I think programming has become more component oriented, which means that you can break down programming more into web developer vs. web designer roles (or app developer or app designer roles) but I don't necessarily think we're even close yet to the drag and drop level of programming, and I'm becoming increasingly convinced that we won't ever be. Programming is the art of dealing with complexity, and all that componentization does is expand the baseline of what can be done.
Can be done faster and cheaper.
Drag and drop is pretty common in the ASP.NET world. It doesn't mean one doesn't program; just that the need for lots of to-the-metal programmers has been reduced significantly. I'm not saying one doesn't need component builders, just fewer of them. The size of a site that can be built and maintained by a handful of skilled and skill sets continues to increase without significant increases in cost.
I think the crunch is only a small crack to the back such as the teacher gives to the student to keep them from sleeping during meditation and to invite enlightenment. Otherwise the difference between component building and assembling components is a matter of where one is on the production line. I don't seen any evidence that we will run out of workers.
Len,
I'm not completely disagreeing with you on this - I think that componentization is significantly streamlining production, though given the number of software projects that continue to fail compared to the overall number, I'm not really sure that it's really making that much difference. Certainly, one of the key effects that componentization (and standardization, which is just componentization of process) has is that it does, as you say, shift software production towards a different model, though I'm not sure that the assembly line is the right metaphor here.
I think its worthwhile to differentiate here between the big software project and the small one. Componentization makes it possible for small software projects to be carried out by fewer people, but those people generally serve more to determine which components to use and then perform the necessary integration. While programmers may (and likely do) specialize, they typically are still experts of the pieces in their domain.
Admittedly, if you talk about a modern assembly line, I'd say the analogy is closer, because in those cases most repetitive operations have been automated, and the occasional person exists primarily as a decision maker, as a designer (which is a decision maker of a different sort), or as a maintenance worker to keep the machines humming. Significantly, all three of these sets of skills require a high degree of training and education, and all three represent a fairly significant degree of autonomy.
I also suspect that the H1B defeat in the Senate may very well end up hurting the software companies, though not IT in general. I do not buy the contention of the BSA or other software company alliances that the H1B visas are truly necessary - they represent cheap labor for these companies, who are now going to be forced to pay more for the home grown variety, but I suspect that global demand for software talent and services will only grow with time (because customization is, ultimately, the metier of programmers). Software companies exist to create "business components" - software that fulfills a certain requirement broadly enough that a large number of companies (or individuals) will buy that software.
Customization is a counterveiling force to commoditization - software companies want to create commodities, because they make less money when they sell to fewer customers (especially in the face of rising labor prices). Customization, on the other hand, is what the customers want - applications that are written specifically to their needs and wants, and while price is certainly a factor, it's not the only one. Open source works on a purely economic level because it makes the cost of the components cheap to non-existent, which in turn means that the primary costs become the integrational labor (the customization labor) - though it also has the effect of pushing down the price of proprietary components.
Note additionally that as the components themselves become more complex, the amount of work necessary to integrate those components to the specific needs of the company also increase. The complexity never completely disappears, because that complexity is driven largely by the customization aspect of the equation.
Some programmers will be needed to build the components in the face of changing technology elsewhere; other programmers will be needed to manage the complexity of integrating those components, to handle the customization. I don't care whether your language is C++ or .NET or Java or ___fill-in-the-blank___, that much will remain true. I think as the number of components continue to rise and the capabilities of the components themselves evolve, the focus will shift increasingly to the second group, but I'm not sure their job is necessary any easier, it just works at a larger scope - the requirements gathering and analysis phases, distributed computational systems, and so forth that you mentioned in your first comment. Those are engineering tasks, not manufacturing ones.
I love your comments, by the way - they tend to focus the mind wonderfully.
I did want to dissect one of your statements in greater detail:
I think the crunch is only a small crack to the back such as the teacher gives to the student to keep them from sleeping during meditation and to invite enlightenment. Otherwise the difference between component building and assembling components is a matter of where one is on the production line. I don't seen any evidence that we will run out of workers.
I'm not a big fan of large corporations, in general. They tend to resemble feudal fiefdoms far too closely for me to take a lot of comfort in their existence. Thus when I hear the talk about labor shortages by companies, I usually take a look at where they are getting there work done first, and by whom.
I do tend to believe that the current crunch is due in part to the dawning realization on the part of the hiring agencies at these corporations that global demand for engineering talent is on the rise, and their ability to bring in lower priced talent from outside is diminishing.
Moreover, demand tends to beget supply, though I suspect that, just as in the case of the oil companies not building up their infrastructure at times where demand is low (because they spent money on fancy buildings, extravagant parties, etc. when the money was there), their ability to move people through the hiring pipeline is currently fairly impaired.
Will the pendulum swing the other way? Certainly, though not for some years yet. There was a huge glut of people that entered IT in the mid-1990s, most driven by IPO madness, just as there was a huge glut of people that entered into real estate services in the early part of this decade. IT had a fairly significant shaking out during the tech winter (just as it's probably not a good time to be in mortgage banking right now). This glut coincided with the rise of the Internet, the rise of component oriented software development, the dramatic increase in the number of powerful PCs, and not coincidentally the entry of the GenXers into the marketplace.
We're now just off the peak of that population wave, heading down. There's a minor peak - the grandchildren of the boomers, on its way in about seven years, and the children of the GenXers, the Millenial babies, are now in second grade (my youngest was born in 2000, so she's at the very forefront of that next generation), so they'll enter the workforce in significant numbers in 2020.
Significantly, both of these peaks are actually smaller than the boomers (the millennial generation is significant in that it occurred at a time when the birth rate fell below the replacement rate), though because they overlap somewhat, you'll actually have two pulses spaced about five years apart with a plateau (and maybe a minor secondary peak) in between them. Thus, things ought to look pretty good for programmers in general for the next five to seven years on demographics alone.
Of course, by then, the interesting areas will likely be in bioinformatics and biocybernetics, nanotech derivative efforts in materials science, energy systems, robotics and aerospace, and pure information sciences will look positively primitive in comparison. If I was graduating from college now, I'd not be interested in information technologies, unless it was a minor to some other areas such as biology or space systems. You will still need programmers, of course, but the skilled engineers will be cross discipline, and the business programmer will look positively antiquated, which needs to be taken into account.
We're not that far apart on this, but some other metrics.
1. Note Spolsky's article on hiring programmers that Elliotte pointed out. Note the need for non-programming skills beyond the need for ATL knowledge. English proficiency rates highly. These non-tech skills are becoming another limiting quality but also are a force pushing us to invent new ways to communicate. As the tech lead for a team that includes two non-native English speakers, it makes a difference but not one I can't overcome.
2. Note the articles starting with T. Bray's reference to the DevChix complaints about leering bullying males. Note the comments about declining numbers of women in the business. There are social status forces at work here too.
But componentization is not just a force working at the lower levels such as the frameworks, eg;, .Net. Microsoft and others are componentizing above that level in software fitted to a particular business so even the jobs of customization you refer to are being pushed up a level where it is becoming more of a form/fit/function analysis plus scripting. How far that will go depends a lot on the analysis and design of the classes. I'm fascinated by the ASP 2.0 changes to the framework and where the difficulty shifted. In the goodOldeDaze I could open the HTML and find everything I needed. Now I have to wade through layers of components designed to hide the complexity of the server from me just to figure out why a certain directory (APP_DATA) can't have a jpg in it. It turns out I had to find a blog commenting on that because MS never tells one this in a place one can find reasonably quickly. So a software design feature wastes a half day of production because a) it is counter intuitive to experience and b) no one bothered to document it transparently.
So even with the componentization, we lose time in complexity of the hidden couplers, technical, social, skills, and competence. Costs are hard to track but it is clearly evident that for the scale of software projects we can deploy, we need fewer workers. Unless of course one is taken over by a distant equity firm that demands absolute control AND cost cutting, thus increasing the numbers of bean counters (Process Design: One Person == One Fact. NeXt), slowing down production and ultimately failing to create value with a company except at the point of resale. Weird but it seems there is no lack of suckers for voodoo economics in the world today (Yes! Matilda Build Virtually And Cash Out Real Before the Pyramid Collapses!).
Does the economic picture change? We rely on computers in ways we never have in the past and this sea change is of such recent emergence that we actually don't know what will result based on experience other than as I said, things speed up. Will we develop more efficient communication, more efficient production based on more efficient tools, better social skills or just learn to accept that as the status of being a computer professional drops, some will go elsewhere to find status. If so, then salaries rise and perhaps in social terms go back to being what they were in the 70s relative to today's costs of living. As that happens, the status point shifts and the flow tips back in the other direction. We've seen this before in America. The Space Program cranked out a lot of engineers and practically created the modern software market. Then in 1971, it began to die at an incredible rate. Then it picked up when a combination of technology and economic forces put the money back into the market.
You enjoy computer science. For others, it is just a job, but when the big numbers are considered, only money matters. So it seems. What interests me more is where these tidal forces will impact software quality just at the point that the complexity can only be managed by the computers themselves and we are so reliant that we can't manage a work stoppage.
Again, I agree with you on just about everything you've said. Comments inline:
<snip>
Note the need for non-programming skills beyond the need for ATL knowledge. English proficiency rates highly.</snip>
One of the reasons I suspect that the Indian outsource market has outperformed the Chinese ... India has 100+ years of British colonialism to insure that English is still largely a near-native language for their technical workforce. More people worldwide speak Chinese than English, but most of those people are concentrated in China, whereas English is a second language almost everywhere its not a primary one.
<snip>Note the comments about declining numbers of women in the business. There are social status forces at work here too.</snip>
Absolutely. Programming has long been dominated by young (not terribly well socialized) males, as much for socioeconomic reasons as anything, and young men are notorious in using their work environment to establish their social position (my code's cleaner|more compact|more elegant|whatever than your code). That's a topic for another time, however.
<snip>But componentization is not just a force working at the lower levels such as the frameworks, eg;, .Net. Microsoft and others are componentizing above that level in software fitted to a particular business so even the jobs of customization you refer to are being pushed up a level where it is becoming more of a form/fit/function analysis plus scripting.</snip>
Yes, though this comes with the danger of biasing the business logic towards the Microsoft way of doing things. Still, t'is a good point.
<snip>In the goodOldeDaze I could open the HTML and find everything I needed. Now I have to wade through layers of components designed to hide the complexity of the server from me just to figure out why a certain directory (APP_DATA) can't have a jpg in it (...) So a software design feature wastes a half day of production because a) it is counter intuitive to experience and b) no one bothered to document it transparently.</snip>
Componentization is hard ... even after more than twenty years of doing it myself, I find the process of task decomposition to be a remarkably difficult and treacherous discipline, very much analogous to the designing of good schemas. The irony here is that the process of creating such components is in some respect becoming easier than the process of designing what the components should do in the first place (namespaces!! Aaaargghh!!!)
<snip>So even with the componentization, we lose time in complexity of the hidden couplers, technical, social, skills, and competence. Costs are hard to track but it is clearly evident that for the scale of software projects we can deploy, we need fewer workers.</snip>
Granted. However, we have fewer workers. The question that I think will shape the software development universe is whether the declining pool of technical competent workers is in fact still larger than the declining pool of programming and IT slots. If the problem is simple economics (software producers are not willing to pay for local talent so long as less expensive remote talent exists) then the solution will be market driven - if the value proposition of the product exceeds the cost of hiring the programmer by some currently unknown factor, then salaries will go up until that is no longer true. If the problem, on the other hand, is fewer trained programmers and a collapsed training pipeline, then production will slow until stasis is reached.
<snip>Unless of course one is taken over by a distant equity firm that demands absolute control AND cost cutting, thus increasing the numbers of bean counters.</snip>
For every project that has failed because of insufficient software, I'd wager that ten have failed due to building too many layers of bureaucracy, each bureaucrat of whom justified their existence by imposing more and more oversight on software projects. Some oversight is necessary, a great deal of it is highly counterproductive
<snip>You enjoy computer science. For others, it is just a job, but when the big numbers are considered, only money matters. So it seems. What interests me more is where these tidal forces will impact software quality just at the point that the complexity can only be managed by the computers themselves and we are so reliant that we can't manage a work stoppage.</snip>
It's coming soon. The biggest constraint on it happening now is that we require a level of accountability and legibility in our software that computers generally cannot produce (computers are poor at creating abstractions at this stage, which is one of the keys to complexity management). As applications become more complex (thinking in the distributed network realm here) I suspect we're reaching a point where the level of computatonal complexity is so high that we may have no choice but to let computers work at their own level of abstraction and constrain the results, especially in the realm of distributed computing.
I'm not sure that will signal the end of programming as a human discipline, but it will certainly alter the balance of power between man and machine in ways that aren't even remotely known.