For example, our once-mighty coal industry has taken a back seat to other forms of energy. I remember coal being delivered to my school in Brooklyn, and I remember the old man who stoked the coke in order to heat the five-story building with 20-foot ceilings. This continued until the 1970s, when natural gas burners replaced the Depression-era furnaces. Even power plants once powered by coal have given way to oil-burning and nuclear units. Generation after generation toiled in coal mines that are now shut. Yes, coal is still used, and the coal industry still exists, but demand has reduced the marketplace, and many of the new generation have not joined the trade of their fathers.
Many steel companies, once the cornerstone of the industrial economy, have now declared bankruptcy or disappeared altogether. Who knew 50 years ago that plastics could be stronger than steel or that imported steel would be the preference of those firms that needed steel for their own industry? President Kennedy railed at the temerity of the steel industry, but today those arguments are moot. There is no significant steel industry to rail against.
Speaking of rails, if Rip Van Winkle had fallen asleep in the 1870s and awakened today, wouldn't he be shocked! The hundreds of railroad companies of a century ago were the economic equivalent of technology in the 1990s. Railroads crossed the land, delivering people and goods from any point to any other point. Rails are still viable today, but they have been eviscerated in favor of less-economical forms of transportation. Extremely few private rails lines are left, and only a small handful operate without some form of subsidy--a subsidy amount that is only a tiny portion of the amount given to airlines.
The commonalities of these themes are substitution, saturation, and imports. Many entities have chosen to use other products or services, have decided to import the same or less-expensive products or services, or see no further need for products and services beyond the current level.
One might wonder then how any of this can be relevant to software when Microsoft, IBM, Oracle, and many other firms have successfully weathered the fiscal storm of 2002. Example after example can be stated of a technology rebound. While these examples cannot be denied, there is a flip side of this record, and I'm going to play that song right now.
A long time ago in the 1960s, or way back in the 1970s, and even just a little while ago in the 1980s, companies were just starting to computerize. These were the days before MS Office was placed on every desktop. These were the days when universal access was a goal, and the "Information Superhighway" had yet to be paved. Packaged software was prohibitively expensive to all but the largest companies. The biggest software houses were McCormick and Dodge and MSA. Packages were sold individually, not integrated, and cost millions of dollars. Those shops using IBM's midrange computers could not afford these packages. The result was that, if you needed the computer to do something in a System/3/32/34/38 environment, you actually had to ask for it!
The process was called "analysis and design," not "architecture." An analyst had to sit down with a group of people and go through a long process of meetings and more meetings before a specification was rendered. The specification was then either approved or worked over. Usually, it was worked over. More often than not, basic financial systems such as General Ledger, Accounts Payable, Accounts Receivable, Order Entry, Payroll, Fixed Assets, Human Resources, Inventory, etc. were designed and coded from scratch. Years of effort, compromises, improvisations, and adjustments to the premises eventually led to the final product. These systems were custom coded to the direct wishes of those who used them. They always responded precisely in the manner that was asked for. Today, we refer to these systems as "legacy systems."
The problem for programmers today is that these systems already exist. Companies are fully computerized. The Internet is here, in all its ubiquity. Off-the-shelf software costs less than ever. There are no more--or at least very few--legacy systems left to build. All companies have their financial software up and running and working. If a new company is born or an existing firm desires to change its software, a package is purchased. The need to code from scratch no longer exists, and all the work that that entailed has disappeared. With that, the jobs created by personal desires--to have custom software work exactly to spec--have also disappeared.
It doesn't matter what platform you are on. The technology is irrelevant. There are no more mountains to climb, no more rivers to cross, no more custom systems to be built, and no more jobs building them. Software saturation has arrived. Programming, or what is left of it, is relegated to patches, enhancements, and augmentation. With packages being so prevalent, the attitude of the end user has changed. Most end users would never give a thought to contacting Microsoft because they want a change in the way Excel works. The same attitude extends now to the use of financial packages. The common response to the question "Why are you doing it this way?" is "That's the way the computer works!" Even the thoughts of enhancement and custom programming are disappearing. People are accepting systems as delivered more and more. Conversely, requests for customization are occurring less and less.
To a great extent, we have reached the point of software saturation. The economic climate alone is not responsible for the dearth of available employment opportunities. Software saturation must also be considered as a contributing factor. Which brings me to the topic of the H1-B visa program.
Originally intended to help companies find resources, the H1-B visa program has allowed college graduates from other countries to enter the United States to work. This program started at a time when resources could arguably have been said to be scarce. Safeguards built into the H1-B visa programmed were designed to ensure that no U.S. citizen would be denied a job in favor of an H1-B candidate. Company after company found the H1-B program to their bottom-line liking. As favor rose, so did the number of candidates. The ceiling grew higher and higher, and finally, the economy did not keep pace. Yet, there is no mechanism to lower the ceiling. Worst of all, there never was a mechanism to ensure that the safeguards worked or that any of the qualifications are met. Many of the legislators who enacted the law and maintain H1-B renewal are only vaguely familiar with the intent, restrictions, and provisions of this legislation.
One congressman has written to me that H1-B "....has helped the United States maintain its economic edge in the face of stiff international competition in the area of computer technology."
Now this is really confusing. If the goals and objectives of H1-B are to maintain an economic edge, then the fundamental intent is clear: The government has determined that United States programmers make too much money and has enacted legislation to remedy the situation. After all, our most important companies--like Enron, Tyco, and World Com--must remain lean. Since Information Technology is a cost center, not a profit center, it only makes sense that cost-cutting take place at this level. Then again, you have the "stiff international competition" to consider as well. I would have to guess (because no one has pointed anything else out to me) that it's those pesky Europeans who produced SAP and BAAN software that we are competing against! But if that's the case, then why allow H1-B workers to gain employment at firms that use foreign-based software products? It is a mystery.
By now, the problems and outright fraud associated with the H1-B program have been well-documented. A quick Internet search on any engine produces a plethora of sites advertising "do-it-yourself H1-B kits" for potential candidates. There is no accountability regarding candidate qualifications: The 18-month, single-employer restriction is routinely ignored; body shops that specialize in H1-B recruitment have no employees of any other kind; and no one ever checks to see if any H1-B candidate is holding a position at the expense of a U.S. citizen.
The H1-B workers themselves are more or less blameless. They did not enact the legislation, and they deserve kudos for taking advantage of it. This is not an immigration program. H1-B workers are supposed to return to their country of origin at the end of their time period, but few--if any--ever do. The H1-B program is not supposed to lead to a green card or residency, but it typically does. H1-B workers are supposed to be paid the prevailing wage, but rarely--if ever--do they get it. Most workers in the H1-B program come from areas where a complaint may be answered with imprisonment or worse, so the authorities receive very few complaints. That is not to say that there are no complaints. Web sites are rife with tales of companies that have been issued nominal fines because of poor payment.
Now, the situation has changed. Now, the times have changed. Now, the economic climate has worsened to the point where no one can claim that there is a lack of programming talent available. And now, many in Congress refuse to lower the H1-B ceiling, reform the H1-B process, or even acknowledge that there is a problem. If the trend continues, university and college Computer Science departments will be emptied faster than the kegs at the dorm, and where will our standing in the "international competition" be then?
Losing one's job is platform-independent. Remember that rail, coal, and steel were victims not only of saturation and replacement, but also of cheaper imports. Now, it gets worse.
In a twist on the importation of cheaper parts and products, many firms have turned to outsourcing for design and programming services. Outsourcing may be loosely defined as the shipment of the full lifecycle of an entire product or project to another firm at least 2,000 miles away.
The biggest problem with outsourcing is the premise. A business entity buys into the outsourcing proposition based on the premise that the entity will save significant sums on salaries and other costs. This premise is based primarily on the initial estimate, which is usually based on a summary specification, which is usually not fully fleshed out. The result, according to brain trusts that write white papers on this sort of thing, is that the result ends up actually costing more than it would have if the project had been performed in-house. And it's not just more dollars; it's more time as well. These studies have also discerned that executives are less likely to insist on custom changes when the people responsible for implementing those changes are a few thousand miles away. Managers are less likely to insist on changes to spec when every change must first get a revised estimate and be approved by several individuals. The bottom line is a delivered system that gives a company everything that they asked for, but very little of what was wanted. Yet many companies continue to outsource their programming requirements.
Part of the reason for the continuation of this practice is psychological. A manager will not admit that his idea was a net money loser. Compromises--some small, some significant--will be made to a project rather than change the concept to an in-house staff. The duration of tasks may be increased, but if costs are measured over a fixed period of time, it will appear that money has been saved, not squandered.
The effect of outsourcing on domestic programming talent is devastating. It has to be difficult to get young Americans to major in Computer Science when they know they might be replaced by foreigners working in substandard conditions earning less than $5,000 a year! I wonder what that does to us in the face of "stiff international competition." If we lose young programmers at the college level, then we lose our technological future. Those to whom we have outsourced our work will eventually know our systems better than we do, and the potential for cyber-terrorism will increase exponentially. It won't take much for some sort of virus, worm, or Trojan horse to completely knock out a vital system. Those in charge will just scratch their heads, because they will not have a technology or programming background. To solve the problem, they'll have to make a call overseas, where the problem may have originated. Do not be surprised if some form of cyber-blackmail develops in the near future. Current business practices are leaving the door open for this possibility, using the "bottom line" as justification.
The fact is that outsourcing is, in most cases, a losing proposition for all concerned. The company that uses outsourcing most often gets an inferior product that's delivered late and lacks customization. The foreign workers who toil on outsourcing projects are being paid poorly, and the programmers who would have created the project are put out of a position.
There you have it: saturation, substitution, and, in this case, imported services. Is programming dead? The answer is an emphatic "no," but then again, neither are rail, coal, or steel. Each operates on a different paradigm. Will new skills make a difference? In the search for employment, additional skills are never a bad thing. On the other hand, it should be remembered that this recession is treating all platforms as an equal opportunity unemployer.
There is not much of a bright side, but much may be accomplished. Many programming and user groups exist across the country, such as COMMON, ICCA, and local user groups. Naturally, user group meetings are spent discussing technology. While this is not a bad thing, it seems that a portion of these meetings should be spent discussing politics. Each group and each individual should develop a strategy for contacting local officials who are responsible for the legislative process. Speakers from IBM and other technological experts are great, but perhaps the group might be better served when the speaker is the local congressperson. The situation might be reversed: Instead of having a speaker, the group may want to invite a guest to listen. So many individuals have their own horror stories to tell. A group meeting of this nature might be very effective.
The legislative remedies are simple: Restrict the use of outsourcing, and reform the H1-B program. There are other measures, such as the repeal of section 1706 of the Tax Reform Act of 1986, that I'll discuss in a future article. In the interim, hang in there if you can. But if you are at the end of your tether and must leave the field, then by all means, do so. There is no shame in finding honest employment in another profession. Many good IT professionals have already abandoned their years of experience in favor of eating and paying the mortgage. They leave their creations behind them to be modified by a new generation that may not come.
David Abramowitz is an independent consultant. He is still hoping for the best at
Publisher's Note: The opinions expressed are those of the author and do not necessarily reflect the opinions of MC Press.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online