"Other Shore" Development is recognizing and leveraging the impact of globalization on the business and process of software development. Customers, Project Managers, Architects, Developers, and Testers all become full partners in the development effort with matched authority for responsibility.

This should not be confused with the more common practice of "Offshore" Development where corporate accountants treat creative talent as fungible human resources and exchange them around the globe like assets and liabilities on a balance sheet (with predictable consequences).

Background

Since starting his first company in 1989, Proteus Technologies' founder Ben Scherrey has been working with developers, testers, partners, and clients scattered around the world. This was not the result of any plan or strategy but, coming from a rural town while pursuing the latest technologies, the lack of local talent necessitated such methods of work. His policy of "going to where the talent is" required leveraging communications mediums and management processes that were conducive to addressing the constraints inherent with such a dispersed talent pool. Upon hearing the term "Offshore" development he initially figured, "That's what we've been doing all along."

The initial rise of Offshore development outsourcing in the late nineties met with mixed results. Anticipated by Edward Yourdon's provocatively titled but certainly insightful book, "Decline and Fall of the American Programmer", most organizations that participated in such activities pursued software development in a manner similar to how one would go about building a factory. Initially to India, followed by former Soviet States, and finally China, early offshore outsourcing successes by companies who mainly needed support and maintenance for their huge legacy code bases caused others to jump on the bandwagon, often with disastrous consequences. Proteus Technologies was called in to help save a few of these failing efforts.

After helping a few clients get back on track with their software development efforts, we realized that the word "offshore" was a very loaded term for the rest of the industry and quite different from what we had been practicing all along. We needed to come up with a new term to define and differentiate what we were doing from what others perceived it to be . While the offshore practitioners were almost universally and single mindedly pursuing cost savings, we had always been pursuing talent, value, and exposure to new markets. Offshore groups were clearly subservient to their onshore counterparts whereas our remote staff were full colleagues who owned their respective areas of responsibility. The only distinguishable attribute between the various groups in our organization was their physical location. We were all on the other shore depending on one's perspective.

The companies that are realizing significant cost savings are rarely recognized as innovators in their industry and do so at the cost of becoming less competitive. This increases their liability that they will be overtaken by a more innovative competitor. This is already apparent in the major offshore markets such as Banglore which has major companies with 30-40% annual turn over rates and just as high wage inflation as the market for "bodies" overheats. Its not sustainable and even when things were "good" quality suffered because it was never a priority.

Blame for these troubled projects was often affixed to general issues of poor remote infrastructure, language barriers, and lack of technical breadth of experience but these same issues were present in even the successful offshore efforts. There was, however, a general trend present in the majority of the failing projects: the "on shore" companies had effectively taken their existing very expensive ineffectual development organization and exported it to become a cheaper ineffectual development organization. The presumption by most of these companies was that they were dissatisfied with their development ROI because local developers were too expensive so management, often at the behest of their accountants, looked for a cheaper alternative. Across the board they failed to consider that their own processes were preventing them from getting the full value out of their existing group. Attributes common to these organizations include:

• Management and Accountants making technology decisions.

  Just as developers are often poor judges when making management decisions, why should one expect different results when non-technical management make technology decisions? How can an organization hope to compete when they start their development group off with one arm tied behind its back because of an inappropriate technology choice for the job at hand?

• Deterministic "everything defined up front" processes.

  Organizations that have convinced themselves that their "Waterfall" development methodology (where all the analysis & design is done up front then passed along to coders) has been working for them are generally self-delusional. The reality is that any "successes" have been in spite of their methodology where developers & analysts often back-fill "required" documentation to fit what was implemented. Reality is quickly driven home when the impact of long-distance development prevents such process run-arounds in the name of progress. The specifications are thrown accross the ocean and months later they get back the worse result that could possibly happen - exactly what they asked for - which is by now clearly wrong or obsolete.

• Lack of ownership & true accountability by development org.

  Software development is a creative pursuit and far from a science. (A computer science professor friend of mine related the brilliant observation that none of the real science subjects actually have the word science in them.) Such an organic endeavor requires smart individuals who have the capacity and willingness to pursue the spirit in which their assignments are given. Trying to manage software development as a industrial factory where such talent is treated as equivalent cogs in a machine destroys any incentive for the very creativity that the job demands. The remoteness of typical offshore development simply compounds this problem.

• Mismatched Authority for Responsibility.

  When individuals are made responsible for tasks but are not given the clear authority to do what is necessary to successfully complete them, the project has been set up for failure. This issue is a resounding theme in the post-mortem of almost all failed projects.

The astute reader will note that these are the same problems that plague all troubled development organizations irrespective of being onshore or offshore. The remoteness of offshore development and the displacement of the natural but undefined processes that really enabled whatever productivity the organization originally had simply undermined all the assumptions driving the justifications to outsource.

Proteus Technologies and our clients that we have assisted in Other Shore efforts have realized significant value returns from our investments that continue to improve each year. When your competition is the typical offshore group, word gets around quickly that you have "real" software projects going on with modern technologies, processes, and challenges. Talented developers seek this out so you get your pick of the top local creative talent while the competition let's their non-technical HR staff manage their recruiting efforts.