|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|May the source be with you, but remember the KISS principle ;-)|
"Any system built without in-house talent produces out-house results."
IT systems are your brain. If you take your brain and outsource
it then any adaptability
you want (becomes) a contract negotiation".
|"We trained hard...
but it seemed that every time we were beginning to form into teams
we would be reorganized. I was to learn later in life that we tend
to meet any new situation by reorganization: and
what a wonderful method it can be for
creating the illusion of progress while producing confusion, inefficiency
Roman author Petronius Arbiter
Copyright 1998-2005, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.
The key observation is that when you outsource everything on a marginal cost basis, you create an inherently unstable operating regime. This is classic “race to the bottom” problem. In case of IT outsourcing the costs that initially are not even acknowledged to exist at all – might come later, and they tend to arrive all at once and by surprise.
When you outsource everything on a marginal
If we outsource IT in the interests of lowing labor costs, we must be mature and acknowledge that there are no free lunches. As you will see evaluating the actual risks/rewards of unbridled globalization of workforce is not an easy task.
Offshore software development and, to lesser extent, moving software maintenance oversees creates complex and expensive to resolve and contain problems that are usually swiped under the floor in the quest for quick buck. In all cases, but especially in "Total Offshoring" cases, those problems tend to increase with the age of the relationship.
In this paper we will try provide a critical
assessment of a primitive offshoring mythology that completely disregards
numerous and complex risks that separation of any function by organizational
boundaries, and large distances (along with cultural and language differences)
entail. We try to show that many inherent in offshoring factors are
connected with the additional complexity of the multi-vendor environment
in comparison with the internal provision of the same services. This additional
complexity tend to offset the cost savings "in a long run". This is especially
true for the "custom software development" type of offshoring products,
the type the author have most experience with. Unlike production of commercial
software, the production (and consumption) of commercial offshoring services
leads to dramatic increase in the level of complexity of IT management and
creates multiple levels of dependencies from the outsourcer, the dependencies
that tend to increase with time.
A classification of most important risks is proposed. Loss of flexibility, divided loyalty, demoralization of staff and the difficulties inherent is distributed development and managing distributed workforce requires more complex and more costly coordination that saps a lot of talent and energy of both programmers and, especially, managers on both ends of the phone line, so to speak. It should be stressed again and again, that mitigating such risks requires top level of management talent. We will argue that such talent usually is not present in firms attempting offshoring as offshoring in more then one way is a sign of internal problems of IT department with the excessive bureaucratization as probably among the top.
I think few writers on this topic understand the scale of the loss of operational flexibility that is inevitable due to more rigid and formalized nature of outsourced development and maintenance as well as shift in attitudes of the remaining staff. And that alone can be very damaging to the competitiveness of the organization, the very notion that brought offshoring into the spotlight. We will also try to show that outside of few well defined and very finely specialized areas offshoring usually increases, not decreases the level of bureaucratization of IT departments.
|...it is worth pointing out that the disfunctional international financial system makes things worse. Offshoring may make sense to firms today, but it doesn't make sense economically. Why isn't there something better for the thin layer of well educated workers in poor countries to do with their education that covering medium skilled in the west remotely? Because misaligned exchange rates depress median incomes in their own countries - that is why!|
People are better then institutions
Prince Peter Alexeievich Kropotkin
This paper is mainly limited to issues connected with software development. It does not cover other areas of offshoring in details and its conclusions are inapplicable outside the state scope of the paper. When we are taking about offshoring in this paper the term should be understood as "offshore software development/maintenance".
We will generally distinguish between outsourcing: hiring other organization to perform certain (or all) IT functions and IT offshoring. The latter is a special type of outsourcing when the substantial part of work (understood as a software development work in this paper) is transferred into other country, typically in a different time zone and requiring long distance Internet or private lines connectivity. Often this country is India (the largest software offshore in the world) or other South Asian country, although offshoring to Eastern Europe, Ireland and other lower wage countries is also practiced, but to a more modest extent.
India's exports of software and services such as call centers and back-office operations totaled $23.6 billion from March 2005 to March 2006, up by 33% from a year earlier [National Association of Software Companies (Nasscom) data]. It's unclear how much of this money is related to pure software development efforts. Offshoring can also be performed via multinationals. One example of using this approach is IBM which cut drastically its US workforce and expanded workforce in India:
IBM has invested $2 billion in India in the past three years. The $6 billion investment announced today will go toward the cost of increasing its workforce, expansion of IBM's facilities in the country, and projects such as education and health that the company is working on with the Indian government, said Shanker Annaswamy, managing director of IBM India. IBM did not, however, say how many additional people it will be hiring in India. IBM's Indian unit is already the largest of any country outside the U.S.
As part of the investment, IBM is setting up in India the first in a new kind of IBM service delivery centers that deploy processes and technologies to automate IT services delivery, the company said. After the pilot is complete, the technologies will be rolled out across other IBM service centers. It is also setting up a Telecommunications Research and Innovation Center at its lab in India. The new center will serve as a key resource for IBM's telecommunications companies around the world, the company said.
We will not explore "multinationals-bounded" type of offshoring in this paper and concentrate mainly on the type of the relationship where outsourcer with its software development specialists is mainly based in foreign country with minimal (often via intermediary or tiny local office) local country presence. We also will not explore small teams outsourcing efforts, when a couple of high level software developers are cherry-picked in some remote country and are paid to work on the complex, challenging project for a particular foreign company. This paper is mainly about institutional outsourcing of programming projects that usually involves considerable number of people on both ends of the phone line, with offshore software developers organized as a separate legal entity -- outsourcing company.
According to the Yankee Group statistics, the offshoring market is estimated at 11% of IT or about $150 billion globally. Fortune 1000 enterprises spend, on average, about 3% of their revenues on IT ( the figure varies from 7-9% in financial sector to 1% or less in manufacturing industries).
India is the largest offshore destination with approximately 1 million of IT workers involved in offshoring (2% of worldwide IT revenues and workforce). There are approximately 5 million IT workers in the USA. That means that total Indian IT workforce approaches to 20% of the USA IT workforce. The vast majority of the revenues of the Indian software developers come from large, established companies. The average sited saving are 20%. The numbers mentioned in IT press can vary form 20 to 80%.
Even from limited analysis of large software development offshoring deals in the USA, it's clear that after three-five years many companies run into fundamental problems. One important, almost unreported trend is that the savings tend to diminish with the age of outsourcing/offshoring relationship, but dependency on the outsourcer tent to increase with the age of the relationship.
Like with marriages not all offshoring software development relationships ends peacefully. And not all of the them produce healthy children -- software for a particular company. While cross-border software development problems are usually carefully swiped under the carpet, in few cases the resulting problems became so severe that they leaked to the press. AT&T Wireless was a good example of the latter, the company where the key ingredients of troubles were mix of SAP/R3 deployment problems and offshoring, not just pure offshoring. SAP/R3 adaptation to particular company can be considered to be a pretty complex software development project with SAP/R3 as a development toolkit.
As a rule of thumb, the press coverage tends underreport the risks of IT offshoring while advantages (and there are several of them too, including, of course, potential cost savings) are systematically overhyped:
According to a recent CFO Research survey, the most critical areas for technology delivery — and those that present the toughest challenge for companies — are selecting implementation partners; implementing hardware, software and process redesign; and change management and staff training. To improve their chances for success, companies need to focus on risk analysis, both within the company and with their partners and strategic vendors. While most companies factor operating performance, cost of technical failure and security into their risk assessments, few consider the risks of misalignment with business needs, regulatory compliance and HR/organizational risk.
It looks like the level and the severity of problems connected with offshore software developemnt is company size dependent. Large organizations are vulnerable to wider array of offshoring software development problem and the severity of each generally increases with the size. Moreover many offshoring software development problems that we will discuss below in less acute form are typical for any large multinational corporation and are inherent for any project with staff separated by large distances as well as cultural and language barriers. At the same time smaller firms in many cases can use specialized services provided by outsourcers more successfully.
In this sense offshoring in a large companies might be connected to more general problem of the level of management talent in a particular (usually "old") organization (Software development offshoring is often inversely correlated with the level of understanding/appreciation of IT by top management). Or it might be that the chain of events that starts with offshoring has some inherent destructive effects of the company IT management (cuckoo effect ? )
The first step in understanding the situation is to recognize that in
a world of software development offshoring Kafka begins to make sense.
I am far from being so naive to claim that my observations are completely
right for all offshoring software development relationships. Like in marriages
there are some made in heavens. I am talking here mainly about an
average case without too much mutual love (and respect) and about specific
areas of offshoring of non-standard application development and subsystems
(with lion share of Web frontends development) as this is an area
where I have the most experience.
For standard IT functions and subsystems like WEB hosting, mail, etc risks are slightly easier to contain. But risks are raising dramatically when the function is less standard and software development is one such function. One example production-related supply chain applications are directly linked to the competitiveness of the company as companies with full scale implementation of SAP/R3 suddenly realized. And they are more difficult to outsource.
In those cases it is important to see a different perspective which is often hidden from the view by somewhat sycophantic IT press (we all like free subscriptions and don't ask question who is paying the money at the end of the day, don't we ;-)
As a first step to managing risks, many countries require companies to conduct risk assessments. The latter usually tries to identify top risks and evaluate how serious each risk is. May be this paper can provide some help in identified risks for the companies that are entering the path of IT offshoring on non-standard applications.
In no way I would like to try to discriminate between programmers or managers of different nations: there are many talented individual programmers (and managers) in any nation, especially in nations with high quality university education as well as in any nation with a large population pool.
In no way I would like to try to discriminate between programmers or managers of different nations: there are many talented individual programmers (and managers) in any nation
Still this is not exactly the matter of the level of talent involved. Even if the talents pools are equal or even the other side is superior (actually, especially, if the other side is superior), offshoring is never a risk-free option. Moreover due to complex interplay of distances, cultural differences and income levels it is very difficult, if possible at all, to understand all the risks involved when the contract is negotiated; there is no free (cost cutting) lunch: complex ( and expensive to solve with the framework of the relationship) problems inevitably surface in any sizable offshoring project.
Below we will try to classify the problems that are already known and reported in the literature but are usually swiped under the carpet in mainstream discussions of offshoring. This is just the first attempt of classification of the known problems as such it is definitely not complete. Still I hope that even in present form it might be useful. Here is the list of seven risk areas that are the most important to understand and, if possible, contain in any large scale offshoring effort:
IT offshoring usually a sign that "Something is rotten in the state of Denmark" in this case in IT department. The most plausible assumption is that the internal IT department reached such a high level of bureaucratization and that management position are occupied by incompetent people who manage to get promotion due to political factors inherent in excessive bureaucratization and first of all favoritism and nepotism (the latter is much more common in modern organizations then people assume). Often IT department became a roadblock for operational units, not a helpful function that the company values. That also means that the feedback from business to IT management is dangerously weakened and business units do longer not care if IT department is internal of outsourced, judging that it cannot be worse. In many cases they are deeply mistaken.: if IT management itself is part of the problem and if talented IT managers are no longer with the company the offshoring only amplify those weaknesses.
This danger of management incompetence on both ends on offshoring chain, and first of all gross incompetence in the host company is the question that is rarely discussed in mainstream IT press. In one of rare articles on the topic How companies court disaster in offshoring deals published in Computerword OCTOBER 30, 2000 Geoffrey James wrote:
The days are long gone when top executives were so computer-illiterate that they refused to have a computer on their desks. But there's still an impressive amount of executive stupidity floating around. That's particularly true when it comes to offshoring, especially when such deals go sour.
Problems in offshoring deals are far from unusual. According to a recent Dataquest study, more than half (53%) of all offshoring customers report having renegotiated a contract, and in nearly one-quarter of these renegotiations, the vendor lost the account.
As a result, litigation and arbitration over failed offshoring agreements is now a big growth area in computer law, says attorney Tobey Marzouk, a partner at Marzouk & Parry, a Washington law firm that specializes in such cases.
A big source of offshoring failures is the way that offshoring vendors tend to "sell high," pitching their projects to the CEO rather than to the IT staff and managers. One of the perversities of corporate culture is that outside experts are often more respected than inside talent, and thus many projects get sold to top management, which then pushes the IT group to go along even when IT knows that the project is impractical.
Another common piece of stupidity is top management's refusal to hire a lawyer who specializes in offshoring litigation during contract negotiations. While it's true that many companies have legal staffs, software litigation is a relatively new field, and few lawyers have either the legal or the technical training to understand the issues involved. Offshoring contracts must be written carefully so that they identify exactly how performance will be measured, with clear acceptance standards and testing procedures. "That way, you can hold the vendor's feet to the fire to make sure problems are fixed," says Marzouk.
When failed offshoring projects end up in court, the knee-jerk reaction of top management is sometimes to fire the IT manager who was the project liaison. That's monumentally stupid, according to James Johnson, CEO of The Standish Group International Inc., a research organization in West Yarmouth, Mass. He tells the story of one small company that "paid the vendor $20 million and found out that the resulting system not only wouldn't work, but that it would cost $20 million a year to keep running." The IT director - a former employee of the vendor - was subsequently fired. But when the case went to court, the former director appeared as a hostile witness, causing the company to lose its lawsuit.
There are several additional factors that need to be mentioned:
Few, if any, offshoring firms can be objective and unbiased in
making decisions, especially if they are recommended by the managers of
the client company. More then anything else the position of offshoring
firm turn people into sycophants. They usually never question the "revelation"
of the client managers even if they are disastrous for the company. Client
is always right. That can lead to huge architectural blunders that doom
the project independent of the level of execution. Those things are not
limited to offshoring but happened often with complex projects like ERP,
especially in case big consultant firms are involved. Several large companies
went out of business as a result (FoxMeyer, AT&T Wireless, etc), several
were severely hurt (Hershell, etc) .
And the facts suggest that you can get bloated and plain wrong architectural solutions very easily. Bloated Java applications with expensive IBM middleware when scripting languages solution or TCL+C architecture might be a better deal are not that uncommon as outsourcers are not really interested to find the best solution for a particular project and need to take into account the interests of other clients that might be different or diametrically opposite to the real need of the company and preferable architectural solutions. Even excessive componentization can byte: as Java class library hell term aptly demonstrate. Generally componentization helps but only to a certain extent. If overused it became itself an overhead.
Too often offshoring means substituting quantity for quality. This creates additional architectural risks. As Fred Brooks noted long ago the real problem with using a lot of mediocre programmers instead of a few good ones is that no matter how long they work, they never produce something as good as what good programmers can produce.
Also offshoring operations are often operated by a greedy middlemen, not by talented managers. Even if talented manager are available, hopping backwards and forwards on short visits usually does not help; the key management (and their families) have to be relocated to lower-cost markets. And that goal is rather difficult to achieve. In a letter to Computerworld about the article Who's to Blame for Failed Offshoring Terrence Vaughn aptly noted:
In the article "Internal Resistance Can Doom Offshore Projects," Rick Pfeiffer claims that 60% of offshored projects that fail can be blamed on some (local) worker tied to the project. Sure, and as everyone knows, 76.3% of all statistics are made up.
I have a better statistic, and it's true: Top management is in charge of 100% of all IT projects that fail. First they push a hopeless IT project with no relation to the real world, and it fails. Then they fire most of the local workers and announce that they are offshoring IT projects, to the loud acclaim of industry pundits and stock analysts everywhere, while the CxOs rake in millions in stock options. Then, when the offshored IT projects also fail, they blame it on the few remaining local IT workers.
This is very important, I would say fundamental problem with offshoring. When offshoring done on cost grounds alone they usually create new (still mostly unrecognized) dependencies that deprive the offshoring company from much of the operational flexibility and by requiring too much procedures and paperwork encourage Soviet-style bureaucratization (and corresponding type of bureaucrats). Typically security departments are direct beneficiary as security-related spending tend to grow dramatically as a defensive reaction of the organism. The main consequence of the bureaucratization is the loss of flexibility, and sooner or later this lack of flexibility can come back and haunt the company.
In the recent interview Bill Gates noted that "The IT systems are your brain. If you take your brain and outsource it then any adaptability you want (becomes) a contract negotiation". After you negotiated the contact any flexibility you used to have is lost as every change explicitly or implicitly become a contact negotiation. And without proper and timely adjustments there is additional risks that a process will became less stable and reliable with time. If architectural issues are decided by outsourcers, then essentially the company becomes a hostage of outsourcers as it no longer has brain power to access the options and the architecture (and thus the costs) are by-and-large controlled by forces outside your control. That is much more serious risk that many PHB assume: the line between architectural decisions and implementation decisions is pretty fuzzy. There is also associated brain-drain risk – if you outsource important CS functions, you irrevocable erode the capabilities within your firm and it is not clear for whom you are training the engineering talent at outsourcer (see below about attrition risk), the talent that after training will look for a better position in the other company. When problems arise, your own staff can often get management cooperation more quickly, with less bureaucratic overhead inherent when two corporations are involved.
The fist category of factors that lead to loss of flexibility is connected with additional standards, policies and procedures that are usually introduced due to offshoring. Such standard are often written by extremely incompetent people, or by corporate careerists who sense the opportunity for promotion in this environment. The rule is not to try to force something down developers throats and make them conform to a standard is constantly ignored. This usually costs money, sometimes a lot of money. Also the whole atmosphere starts smell socialism.
The other important aspect of the loss of flexibility (that we will discuss under a slightly different angle later) if that the offshoring company can eventually acquire the critical mass of know-how and talent pool in a particular area. In this case the host company became a client of offshoring company not vise versa. Even worse, in more then one way host company became a hostage of the outsourcer: in this case it is outsourcer who can dictate the rules of the game and who is the only party who understands the precise nature of the tasks involved and can conceal this knowledge for his own advantage from the other party. That usually is helped by the demoralization of the remaining staff in the company that outsource a particular IT function.
In a typical offshoring mythology there is no connection between IT architects, programmers and coders as it they are completely isolated and one can be outsourced while the other kept. To put it in other words (or in wider view) this myth ignores an intrinsic links between architectural issues and implementation issues).
In comparison with in-sourcing (bringing programmers, managers from other countries to the country where the project is performed or creating a subsidiary in a foreign country) IT offshoring has higher risks and a lot of hidden/unanticipated costs. It requires complex multi-level coordination and a very precise understanding of the architectural issues related to tasks. Typically unforeseen communication, travel and management costs over the project duration absorb drastically more resources than company originally anticipated. Even simple cases often contain unanticipated difficulties. Most would agree that Dell management is better then average, still they found out that even such simple task as offshoring of mundane support of regular Windows PCs created a lot of tension with enterprise customers.
There's little reason to believe these sorts of risks could prevent jobs from going offshore. Particularly during rough economic times, management often views the need to cut costs to be an absolute priority. The typical explanation is that the choice isn't offshoring or keeping jobs here; it's offshoring or going out of business. But the real questions are:
As for the first question my impression is that often offshoring is not an absolute necessity, but is a layoff in disguise. In this case it does not matter what quality is provided by offshoring firm as it will be only a temporary one, anyway. IBM often is used by big companies is such a way; people are first transferred to IBM and then after a year or so are laid off, but not from the original firm but the new one and that alone provides sometimes a significant cost savings.
Offshoring of IT operations can carry more immediate and more damaging risks for the reputation of the companies than it is commonly assumed. Generally handing price pressures by choosing a sole low cost supplier (and then usually increasing this pressure by trying to renegotiate the terms downwards) is asking for troubles.
Typical IT offshoring with its flawed motives and inadequate assessment of the risks involved sows the seeds that later germinate into the contractual dispute.
When you transfer a process to a third party, it can behave in ways that are opportunistic. It might cut costs at your expense, or use the knowledge for benefits of the direct competitor. There are many facets of this strategic risk and the list below is far from being exhaustive:
Vendors typically ignore or only casually address what happens when the relationship ends and how the customer reconstitutes its operations, transitions to another offshoring vendor or simply winds down the operation. Given the relatively high incidence of prematurely terminated offshoring agreements, it is critical for the parties to structure and document a disengagement process that aligns the parties’ interests and adequately addresses the financial and operational issues presented by early termination.
If a company stops working with the offshoring firm, then all the intellectual property transferred in process might be lost or even walk to the competitor.
Does the service provider own the work that it develops on a customer engagement?
Your offshoring contract should clarify which party owns work performed rather than leave this matter open to question or later negotiation. Vagueness could lead to conflict later on. You and the client should clearly define ownership of the contracted work, whether it's software, business processes or other intellectual property developed over the course of the contract.
Change of ownership is one of the most underappreciated risks. If
offshoring company is not doing well it is often sold and you face the
Practically all vendors’ first drafts include significant limitations on their liability under the offshoring agreement. These limitations include caps on damages, exclusions of consequential damages, limited indemnification rights for the benefit of the customer, and broad indemnification provisions protecting the vendor. Such limits cause customers to have limited or no recourse against a breaching vendor and potentially exposes the customer to massive losses. Understanding these limited remedies and the practical impact of such remedies can be difficult. Negotiating remedies that provide practical and meaningful protections for the offshoring customer is often one of the most adversarial and difficult elements of the offshoring contract.
Creation of exit strategy is very expensive and channeling tasks. Generally the longer offshoring continued the more difficult it is to execute a sound exit strategy without incurring substantial losses, That's why change of ownership is one of the most underappreciated risks. If offshoring company is not doing well it is often sold and you face the consequences.
Attrition reaching 15% to 30% per year is typical for Indian offshoring firms (especially those with boiler room mentality) (NYT data). That means that firms which outsource IT have permanent problems due to "outflow" of skilled programmers and "inflow " of fresh programmers to be trained.
Therefore even if you are lucky and managed to find qualified people for a particular project and get some real (not imaginable/result of aggressive and deceptive marketing typical for offshoring companies, as is often the case) experts expect that those people will soon be gone. Why should they work for a salary 5 times less than they can get elsewhere ? If we are talking about equal opportunities, is not this a discrimination of a kind ?
And in most cases the picture is much bleaker: while getting your
money and training using your resources outsourcers rarely managed to
meet the expectations in application development projects and even more
rarely to produce that product that is really worthwhile. Often
the net result is an increased software bloat and smelly architecture.
Even companies with split workforce (as is the case in many startups)
are having tremendous difficulties operating two distant team and keep
them productive all the time and keep both locations secure despite
the distances. As one friend summarized his management experience/frustration:
it's better to have a team in provincial USA then in metropolitan country
X: in country X you usually either have too much security that semi-paralyze
people or not enough to keep things from flowing out". And
here we are not taking about offshoring but about employers of the same
company who are in the same boat and thus have higher level of loyalty
and enthusiasm; often those people are additionally motivated
by options to buy company shares in case the company will go public
and the possibility to move to, say USA in case of success)
That means that in application development often using a smaller local team is a move that is more cost-effective and productive than dozens or even hundreds of outsourced coders, no matter how you slice the task in hand. In programming quality never can replace quality. And that's probably the only way to get important code which actually works, not those repetitive cut-and-paste monstrosities called "software" nowadays.
The intellectual property used in offshoring transactions includes the
materials the vendor uses to perform the services, such as its pre-existing
know-how and the know-how developed specifically for the customer.
Customers typically share their know-how with outsourcers although much
of this know-how the customer does not want shared with its competitors.
In call centers companies were making themselves vulnerable to insider theft.
Call center collect lots of data about customers and gave ready access to
it to employees who, in turn, had easy access to the internet. Think about
such simultaneously present factors as centralized data, high turnover
of personnel, easy distribution of stolen data. Here we have subtle dangers
that typically get superficial treatment in the press, such as the risk
of leaking corporate intellectual property or data to third-parties.
How you know that your customer data did not grow legs in offshore environment,
or the algorithms procedure or logistics that give your systems a competitive
edge, is not sold to the highest bidder or just given to local businesses?
Who owns, and more importantly, who has the continuing right to use such
know-how can be controversial issues, especially after the relationship
If after the relationship ends the customer does not have the right to use a wide range of intellectual property the vendor used to perform the services, then termination of the relationship could be very costly and burdensome for the company. Addressing topics such as derivatives, residuals and know-how providing a competitive advantage to either party are very difficult and costly and require high level of skills from the managers, lawyers and key specialists of the company. And both managers and key specialists are usually demoralized by offshoring. That's like fighting infection with weakened immune system.
"Truth in advertising" is usually absent and the company often buys "cat in a bag"
There is a notion that Webster calls "the thermocline of truth" the thin like between facts and fiction similar to the thin zone that separate warm water from the cold in the pool. The ability to distinguish facts from fiction is usually absent during the negotiations. Outsourcers are usually pretty creative in marketing: a guy who just finished Novel courses can be sold as an experienced Netware administrator to unsuspecting offshoring lover. It the guy is clever enough, in most cases he will became experienced Novell administrator, but only a year or two on the job; your company job. The same is true about all those fake "The Hero of Socialist Labor" style certifications like ISO-9000 or Capability Maturity (CMM). This is a systemic problem. A lot of people in offshoring companies are neophytes that are marketed as top specialists. Many are recent college graduates, and do not have industry experience. Many will learn quickly. Some will not. The latter are the most dangerous, especailly if important project due to them reached stage when only euthanasia can help:
Euthanasia for the project might be the best course, but people often have too much heart and money invested to end it.
One technique for preventing a disaster is to add some humility to the endeavor. Invite a third party to review your work - a reliable consultant, an academic or a buddy CIO.
An outsider can "walk into the project setting for 20 minutes, talk to a few people and come to the conclusion that things have run amok. But people inside may not even be aware," Keil said.
Greyhound Lines Inc. in Dallas, for example, seemingly didn't know anything was wrong with its new reservations and logistics system - until it went live and 12% of its customers went away mad in one month.
Though specific individuals might learn from their own mistakes, those lessons aren't transferred to any collective IT consciousness.
"The people with that [failure] experience aren't always the people in authority the next time that situation arises," observed Kevin Hickey, a former head of IT at Trumbull, Conn.-based Oxford Health Plans Inc. "The fact is, hubris will always be with us."
And then there's what Webster calls "the thermocline of truth." Swimmers know that lake water separates into warm and cold horizontal bands. The area between is a thermocline.
In IT groups, everyone below Webster's "thermocline of truth" knows the project is sinking, while everyone above it thinks things are fine. Senior executives can be oblivious. They aren't involved enough, they don't want to have to face a failure, or underlings are afraid to tell them, he explained.
"You can see that persist almost until the point where the project is supposed to be delivered," he said. "Then, suddenly, it's, 'What do you mean this will take another six months?' "
That was part of the sorry plight of Fort Worth, Texas-based AMR Corp.'s Confirm reservations system. Confirm managers are even said to have orchestrated a cover-up.
Overall, IT culture is such that problems, especially expensive ones (which hold the most valuable lessons), are hidden. Programmers write around buggy code rather than tear it apart. Managers revise project specifications to reflect what they did instead of what they should have done. Senior IT leaders neglect to tell their bosses the bad news.
Most companies are too embarrassed to analyze their failures, said Effy Oz, an associate professor of management and IT at Pennsylvania State University in Great Valley.
"People will say, 'There's no time, and we're not paid to have these discussions,' " Oz said. "The CEO has to be a very confident person to say, 'These things happen. Let's learn from it.' "
The average loss in an abandoned project is $4.2 million, according to Oz. The blowups in Computerworld's top 10 list cost much more than that. And, if history is any indication, they will happen again.
Business units may also feel that they lost the control to the extent they cannot do their jobs effectively and secretly to recreate a given IT function duplicating costs. The individual and collective desire for control, and the motivation behind receiving and doling it out, creates a politicized atmosphere that lowers morale and has other unintended results. In many cases the information given by outsourcers, especially about the business side of the project, is often not true (to say the least).
Offshoring is considered by existing internal staff as the race to the bottom. Often they charge top management with the hypocrisy. A key factor that set the stage is that many employees are seeing the brass as compete hypocrites, who cut heads without cutting their salaries and benefits. That badly affect the level of trust and breaks lines of communications. Employees start interpreter both the situation the company faces and the values that company adhere differently than the brass. Of course some level of hypocrisy is unavoidable in an organizations, but at some point quantity turns into quality and demoralizations kicks in.It is important to understand that demoralization can have a crippling effect on the "real" productivity extending well beyond the services or activities being outsourced. It is a Trojan horse that can bite in very sensitive and unexpected places and inflate the costs of everything by a substantial margin, often doubling them. This is a typical recommendation from a security training manual:
Disgruntled or unethical employees may be looking to get revenge on an organization. This is very dangerous, because such people know the organization from the inside. The disgruntled employee may know the procedures that are in place, and the best way to bypass them. Be careful when you talk to former employees.
If loyalty is undermined, the behavior of those who survives significantly change. They feel to be "the next in line" and behave accordingly even if this is not true. Typically top IT workers who survived brutal downsizing adjust their professional outlook. "I Thinking "I can be next and I don't try as hard as I used to," they say to themselves. "I used to work 60-to-70-hour weeks and even do work at home on top of that. Now, I'll do my 50 and not make myself sick."
Most will perform fewer discretionary actions that would promote organizational effectiveness. Such actions would include helping co-workers, not complaining about trivial problems or speaking approvingly about the organization to outsiders. In one servey four in five of the survey's respondents confessed that if requested, they would forward company sensitive information to a former colleague, even if they were now working for a rival firm.
While it's obvious that no one should work at the expense of her health, that "I don't try as hard as I used to" comment is the typical sign of demoralization. That means that the company is now facing the danger that existing IT staff keep distance from the job and from management and avoid "putting soul" into it. People who'd seen keep their distance from the job and no longer put in 100% effort. "I won't make the same mistake again by being dedicated," -- a typical sentiment goes -- "It isn't worth it." Wisdom is, in large part, a product of experience, and experience comes with age. And, like any shrinking commodity, experienced workers will increase in value as their availability declines. It therefore seems counterproductive for the companies to estrange the very people who possess a shrinking resource on which it ultimately relies.
That means that firms that went through a transition to outsourced operations, need to compensate not only direct loss of talent and "know how" but also account for a substantial demoralization of staff. Demoralization is a very dangerous (and very costly) problem that actually can cost organization more money then it expects to save via offshoring. More then 80% of act of sabotage in the USA are performed by disgruntled insiders and anger is the main motivation for such attacks. But even without sabotage the possibility of harming the company taking into account typical difference in professional competence of IT managers and key specialists (Dilbert effect) are endless: sending the company in the wrong direction like Ivan Susanin classic can cause more damage then most direct attacks by a disgruntled employees. Procuring unnecessary services is another rich with possibilities path of "less resistance". There are various rather subtle forms of revenge that people who know the ropes can use, if they are really disgruntled. Bringing some monster, expensive but semi-useless "enterprise software system" that otherwise company would be wise enough to avoid is just the most benign trick in the repertoire. Cases where huge expensive servers were bought when a small server would suffice, onsite consultants were indiscriminately awarded $200 per hour wages as well as huge contract cost overruns, etc., are not that infrequent if demoralization kick in. Some companies actually are only one disgruntled employee away from a full-blown BSA investigation [Wired News Dumped Workers Find Revenge ]:
A programmer who worked on a website for an entertainment company said in an e-mail that he turned in his ex-employers when his contract was abruptly terminated.
He asked BSA not to identify him because the company he filed the report on was giving him "a great reference."
But he said he was happy to see that his former employer was fined $473,000 for software piracy after the company's internal audit turned up software that the company could not prove it had purchased.
"We were fired with no warning, the bosses got sweet severance packages and everyone else got a week's pay," the e-mail said. "While the security guards were marching me and my fellow now-unemployed, ex-coworkers out of the building, I figured why not turn them in? I knew they were using hot copies of programs and anything I could do to cause my former employer pain seemed like a great idea to me."
Those who are interested in the effects of the demoralization process
can read an excellent work by Professor Tamotsu Shibutani
Derelicts of Company K A Sociological Study of Demoralization".
Classic fiction book by Jaroslav Hasek The Good Soldier Svejk : and His Fortunes in the World War is also a recommended reading ;-). It exposes what is called the "power of the powerless" -- subverting authority from within while seemingly going along with the grandiose designs of the ruling elite. Joseph Heller once said that if it weren’t for his having read The Good Soldier Švejk he would never had written Catch-22.
In some cases remaining employees can explicitly or implicitly align with outsourcers in stealing software activation keys, using facilities for unrelated to job functions (especially for job search), etc. Here is one interesting comment:
What WILL slow down and even stop IT offshoring is the elimination of IP rents. At present the American OWNERS of the enterprise collect all the rent (return to monopoly ownership privilege) on the software created by the foreign producers. Outside US borders the price of the software is minuscule as pirated copies are easily obtained. Only Americans pay the inflated (rent seeking) prices. Same with pharmaceuticals. Middle class Americans pay the toll as Bill Gates gets richer and richer. If the Indians are as good as the Americans at producing software then why does Bill Gates need to get the rent, and why does software cost so much? It is my understanding that Indian manufacture of pharmaceuticals is much the same kind of deal and if not then the Chinese probably do the pharmaceuticals for sale in places other than the USA. Again: Americans pay all the rent.
The American producer's anger with the Indians taking the jobs is misplaced. The anger should be directed at our own government and its continued reward to rent seekers. If the software were priced exclusive of rent, then we would all (Indians and Americans alike) benefit from the comparative advantage. But as it is, so called, "free trade" is merely exacerbating wealth disparity in the USA and keeping foreigners from realizing the full return to their efforts.
First of all it's very difficult to separate architectural issues from implementation in all but trivial software projects. The second thing is that implementation difficulties serve as a feedback and the reality test for architectural decisions and if this feedback is absent there is a tendency to stick to the first chosen architecture and suffer consequences.
Also a good talented programmer is more then 10 times more productive than an "average" programmer (meaning one that has no aptitude for the profession, and who went in just because it seemed an easy and clean way to make good money). This was well known for decades. Also now quantity of low level coders can create the sound design for the project. If you are talking about architectural issues, then situation is more complex. Of course there are talented programmer of any nationality. But why they should work for pennies for an outsourcer instead of moving to countries where he/she can be paid more is unclear. In any way it's important to stress that a good programmer will simply create programming product of a quality that average programmers never can create. No matter how many of them you can hire...
As Doug McIlroy aptly observed "Any system built without in-house talent produces out-house results.". Bill Gates quote reproduced above is also on to something here: the possibility to outsource all future innovation and become a hostage of the offshoring vendor is too high to ignore. Also the companies who offshore programmers because they're "expensive" is participating in decimation a the next generation of engineers/software architects and, paradoxically, the next generation of IT senior management. The threat of offshoring makes it unattractive for younger generations to entering the field. Especially when universities charge arm and leg for junk courses under the disguise of brand names on their buildings (the crisis in computer science education and the quality of the tenured faculty is another story). Actually in large universities education is semi-outsourced too: often instead of top professor the students are exposed to a recent graduate with a strong accent. And it is he, not the students who is the major beneficiary of the course he is teaching.
You also need to access negative PR consequences for the company that attempt offshoring. Public opinion in the USA became very skeptical. As the refection of it some politicians start to voice their reservations and may push some laws that change the playing field: on the op-ed page of The New York Times, Senator Charles Schumer recently asked "whether the case for free trade ... is undermined by the changes now evident in the modern global economy," particularly offshore offshoring. His answer? A resounding "yes."
Long term implications of offshoring are the problem that is the most difficult to understand. We can only speculate here. But there are two large areas that we can try to address based on circumstantial evidence:
As we mentioned above, offshore offshoring requires very strong management that involves far more communication and management travel than would be expected at first. With enough management talent, over time, any difficulties can be worked out, but it takes tremendous amount time and energy for a strong relationship to be built. the problem is that skills management is a very scare resource that is difficult to find and difficult to maintain and burn-out atmosphere of a typical offshore software projects. Additional cultural differences also creep in.
Generally employees are more willing to share with people they trust and who treat them fairly. Socialogists have found that people tend to engage in knowledge hiding if:
It is easy to see that all three conditions are met in a typical offshoring situation.
On the other side of the fence outsourcer is reluctant to share the ideas that might undermine its revenue base. That means that "business as usual" is a preferable mode of operation for both sides, no matter how counterproductive it is for the organization as a whole.
Companies worry about cross-border offshoring not only because of the potential loss of jobs, which is manageable, but because of the potential loss of brainpower. After an offshoring, the activates that were outsourced move across the border. At the time of the deal it is difficult to understand all the implications including to what extent the activities outsourced are of vital importance for the future of the company. Thus, the loss for the company that outsourced It services becomes twofold.
This danger of brainpower loss is an objective fact - it cannot be brushed aside, labeled as old-fashioned protectionism pursued by people who don't understand the imperatives of globalization. It goes deeper than that. And it cab have political implications that can eventually cost jobs the very executives who initiated such moves. In many companies executives who pushed for offshoring of important parts of business are viewed internally like something in between idiots and traitors. Of course such feelings are masked by obedience, but such deeply held views never help to achieve a career success.
I feel that the only way for a country feel safe in the current world is to ensure that it has the cutting edge industries and an educated workforce that keeps learning. But offshoring undermines the very motivation for learning. Moreover it partially cuts off the oversees talent, who "under previous regime" was motivated to come and settle in the country due to higher standard of living. There is simply no jobs for those people.
Think of the world economy as a ladder. On the bottom layer are the countries
producing natural resources as well as countries which produces only agricultural
products, textiles and some low-tech goods. Toward the top are economies,
which make sophisticated computer electronics and first of all CPUs, software,
pharmaceuticals, plains and medical equipment. The latter are cutting edge
technologies of today. In the middle layers are all the other nations, manufacturing
"cutting edge technologies of yesterday" everything from steel to autos
and less sophisticated electronics. Viewed in this way, economic development
is simple: everyone tries to climb to the next layer, get into more advanced
and more lucrative industries.
This works well if the topmost countries can constantly create new industries and products. That allows older industries to move overseas while fresh jobs are generated at home in new industries. But if innovation stalls then the country found itself in trouble as in the absence of protective tariff barriers that help to preserve existing industries despite existence of cheaper foreign competitors jobs are moving to loser cost countries. That means that without new industries on the horizon, offshoring can do for IT the same it did for manufacturing jobs earlier. History does offer cause for worry. There was a period, from 1973 to 1985 (1985 was the start of PC explosion) when technological change contributed almost nothing to growth, according to government data. Not coincidentally, that was also the same stretch when U.S. manufacturing became vulnerable to foreign competitors and eventually largely disappeared.
In IT initially only low-skill software and support jobs were the ones sent to foreign firms. But now we are seeing better jobs, even new development jobs, going overseas. While "top guns" still can survive, that creates a grim situation for less-skilled American workers employed in IT. Before, they could take, say, call-center jobs or operator jobs or even "code monkey" jobs, prove themselves, acquire more skills and advance to better-paying positions. But with those type of jobs leaving the country there’s no longer the ladder that you can climb up. You need to go to Wall Mart or McDonalds, get a "Mac job" and stay on this job for the rest of your life.
While "outsource or perish" zealots are trying to connect offshoring to avoiding business closures now, its biggest impact may be longer term. Quantity eventually turns to quality and with a wide array of mid-level professional jobs moving offshore some structural changes might be underway in the US economy. It also means that for current students the career you studied for -- and spent a lot of money on -- probably won't sustain you for your working life. This structural change could result in a far worse job picture 10 or 15 years down the road. All this talk about retiring baby boomers is just a hot air. Despite this generation retirement the U.S. workforce may face frequent career changes and downward pressures on wages.
Charley Reese once mentioned the other dimension when he discussed off-shoring manufacturing jobs, but I think that this is applicable to IT too:
Manufacturing jobs are the gateway to the middle class. Losing them is lowering our standard of living. Losing them because the federal government does nothing to stop the loss is poisoning Americans' belief in their own government. Eventually, America's defense needs will become dependent on foreign imports. Allowing that to happen is treason by fools.
We can view this situation also under another angle. One important
nor rarely openly discussed incentive for offshoring is dismantling
of a current lucrative IT labor sector. Understanding that the expected
side effect of offshoring is "devaluation of IS/programming jobs" and putting
most programmers where they belong from the management perspective ("proletariat
of mental labor" if we reuse old cliché here make understanding of some
paradoxes inherent in offshoring easier. If management actually is
preoccupied with shifting the labor to devalue the jobs the last thing that
they care is if the companies in India or Philippines or elsewhere are perfect
or not. The offshoring provider can be well a "Potyomkin village" type of
a company, not capable doing any useful job at all (and some probably are).
But if the purpose is to dismantle the labor sector this situation it's
still OK. As long as they can push the reorganization and related
layoffs to produce cost savings the game is still worth the candles: IT
budgets drops to the level below 1% in large non-IS companies and most of
the hate wave goes in the direction of offshoring companies, not the current
management. If survivors might not be able to cope with the increased workload
that's a separate problem. And it's not bad if offshoring completely
fail as long as the period is a couple of years or more; then in two-three
years there is a new situation and new career opportunities (as in
saying "if you can invade the country do it; later you can hire whatever
you want to justify the decision").
In this respect the important side effect is that excesses of Y2K and Internet bubble can be eliminated and 40K of slightly depreciated dollars is now again a viable salary for a pretty highly trained Unix admin/programmer in the USA. Moreover the level of unemployment among IS personnel is sufficient for find any kind of qualified peoples for reasonable (from management point of view) prices. And complex contract jobs now sometimes go for "net" $20-30K here in the USA without any India. That actually might mean that dollar was revalued, not devalued in this particular areas.
While outsourcing is often performed in the name of efficiency, outsourcer is not motivated to perform the most efficient job. The key reason the outsourcer is in this business are profits and the ability to "milk the cow" by exploiting the existing complexity of the infrastructure and inefficiencies for reaping additional profits are two factors that makes outsourcer reluctant to implement any significant improvements. If in addition the vendor feels the company reached the condition of "vendor lock in", the offshoring vendor has the upper hand in any strategic negotiations and can explicitly (or better implicitly) raise the prices without raising the quality of service.
This level of dependence increases over the time with the first milestones
reachable probably in three to five years of relationship. As soon as local
talent is gone the organization lost important part of the organization
IQ. That usually correlated with the drastic deterioration of quality of
management staff. Dumber organization makes dumber decisions, especially
the most important architectural decisions. And no amount of glossy
presentations about quality of service, six sigma courses or certifications
can change this situation.
The implicit pressure to cut costs also play important role in deterioration of services with the time. I heard interesting stories about how Indian companies now are suffering from the competition from Filipinos, mainland China and like. They might be losing some offshoring contracts because it you want cheap labor, India is no longer the only place to go, not it is the lowest bidder. That means that there is an increased pressure for Indian firms will try to find offshoring subcontractors to do part or all the job to save costs. In Computer Counsel Six Issues Facing Offshoring Service Providers - Computerworld this item is worded pretty explicitly:
Does the service provider have the freedom to move services offshore or use subcontractors as a cost-savings approach?
To reduce costs, your offshoring contract should provide that you may relocate services and work with subcontractors of your choosing. The customer will require you to negotiate appropriate confidentiality provisions and may attempt to assert other limitations on these rights. The key to securing this right is to guarantee clients seamless, high-quality service.
At the end I would like to remind again very apt observation of Bill Gates "The IT systems are your brain. If you take your brain and outsource it then any adaptability you want (becomes) a contract negotiation".
While a universal phenomenon, nepotism and corruption are more prominent in Asia then in the USA. As offshoring companies pay above average wages they are natural dumping ground for all sorts of relatives of influential politicians and top IT managers. That means that such companies have high internal overhead and top heavy bureaucracy. Here is one telling comment related to the lowest type of offshoring, helpdesk offshoring:
When we debrief the Indian reps, they always say the same things: "Sir, I did the necessary and escalated the call. The customer has become irritated." "Sir, the customer asked me something new. I have pooped myself and now must ask for an upgrade of the incident". "Sir, I am not prepared for this. I have a decent job that pays me a living wage solely because of who my parents are." The caste system is alive and well, and working for all the Kumars and Rajs of the world, thank you very much... "I graduated first in my class with a master's at age 21 in English studies, but I only learned by rote and cheated most the time. This is acceptable."
"Discarded and Demoralized"
[Harrison2005] Warren Harrison The Sabateur Within IEEE Software. From the Editor
[NTAC2005] United States Secret Service National Threat Assessment Center (NTAC) Insider Threat Study
[HBS2004] The Offshoring Revolution HBS Working Knowledge
[Noble2005] Scott Noble Why Offshore Offshoring Projects Fail - IT Observer 20 May 2005
[Vaughn2005] Terrence Vaughn Who's to Blame for Failed Offshoring, 3 - Computerworld
[James2000] Geoffrey James How companies court disaster in offshoring deals Computerword October 30, 2000
[Bertch2003] Wesley Bertch How Offshore Offshoring Failed Us Network computing | October 16, 2003Software Testing in Offshoring - Under Funded and Not Thoroughly Conducted August 2005
3.10 Offshoring - Grundschutz Manual 1.7
You Can't Outsource City Hall - GOVERNMENT OFFSHORING - why state and local government IT offshoring is a bust; what some governments are doing as an alternative to wholesale offshoring - CIO Magazine Jun 15,2002
Poor communication stymies IT offshoring - IT Week
Buyer Beware - Offshoring - CFO.com
Offshoring Risks Worry the Wary - Offshoring - CFO.com
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: September, 12, 2017