Tag Archives: offshoring

Prerequisites for Offshoring

One of my clients was trying hard to outsource software development, and has implemented processes for identifying candidate projects. The rules were pretty reasonable:

  • Existing software is documented in a suitable way (from requirements over specification and design to programming and rollout). “Suitable” means “competent people without prior knowledge of the project have access to enough information to extend the software successfully with reasonable effort”. That, by the way, is a pretty good definition of the quality any documentation should have.
  • The customer is aware that development is being done offshore, is willing to live with that, and accepts that documents provided by him to the project and documents produced by the project are written in English.
  • Processes are in place that allow for clear specification of stable requirements, and clear separation of phases and responsibilities.
  • The offshore workforce is reasonably stable so trained personnel is available over a longer period of time.

The problem was that pressure to increase the amount of offshored projects was so high that projects got moved to India, no matter the cost – ironically.

Here an example of a gone wrong (= more expensive then before) project transition:

  • The existing software was developed under high pressure, meaning “coding before design” and “we’ll do documentation when we have time”. That meant no overall design, and no documentation.
  • The customer did neither produce nor accept documentation written in English. All documents exchanged with the customer had to be translated at additional cost that couldn’t be billed to the customer. Translation was done in India, and results had to be proof-read by German personnel.
  • Because of sluggish processes a of lot of time got wasted between the customer voicing a request and the production of usable requirements.

The offshoring guidelines were very reasonable, but they were completely ignored. I can’t give any other advice than to “stick to the plan”, if the plan is reasonable.

Comparing Work by Cost Only

A company I worked for recently stated that “the internal hourly rate has to be brought down to xy Euros” in order to compete with other companies. This argument was mainly made to emphasize the importance of doing more (cheap) work off shore, thus lowering the average hourly rate.

Somewhat concerned I looked at the sentence for a while, thinking about whether this might be hinting at an unpleasant development that could have implications for me as a freelancer (I never ever have worked for as low as xy Euros per hour).

Then I relaxed.

You only may compare prices for specific services rendered if you are talking about the same kind of service, “the same kind” as in “same amount of work done per unit of time” and “same quality”. When buying a car you would never look at the price only: What make, what model? How old is it, what is the mileage, what is the condition?

Compared to German programmers, offshore resources only cost a quarter – on paper. In reality, the offshore partner regularly puts more people at the same task then the German side would. Some key people of the offshore partner will receive training on the project in Germany, and there will be a permanent on-site manager. So, add travel and hotel expenses, plus lost work time on the German and offshore side.

What if the customer doesn’t like documentation in English, and the offshore partner does not understand German? Ka-ching, add cost for translation, and load your tolerance module for accidentally introduced errors. And then, oops, personal that was trained in Germany leaves the offshore partner for sunnier shores. In the end, the cost is closer to 75% of the German rate.

“75% of the German rate” still doesn’t sound all bad. But this is for the development portion only. Sales, marketing, project management, requirements analysis, specification, design, testing, and roll out is all done in Germany. Development maybe is one third of the overall cost. In the end you would save about 8%.

“Saving 8%” is not nothing, right? Yes, but are you sure there aren’t any other ways to increase productivity, which essentially means getting more bang for your buck? Offshoring often has the side effect of alienating people working for you “at home”, and in my personal opinion offshoring is doing your local economy a disservice.

Why do people start with offshoring when they try to save money? When optimizing a program you start with an analysis first, identifying the code where most of the time or memory gets consumed. It is here that optimization effort gets you the greatest effect.

Blindly aiming for a lower hourly rate by using offshore resources is a brute force approach that does not look at underlying causes that drive cost up.

There are quite likely easier ways to improve productivity then transferring work abroad. Analyze your cost structure. Start working on the biggest items first. Review you processes. Educate and cherish the people working for you. Try a little harder at home!

Breaking Up Architecture and Development

From practical experience, the emphasis in “breaking up architecture and development” is on “breaking” – it does not work.

A customer I have been working for decided to split software development across two different organizational branches: project management, specification, and architecture on one side and software development and testing on the other. The transition to this organizational structure was made in a “jump into cold water” fashion.

The idea was that the high level and therefore expensive work would be done in Germany and the low level cheap work would be offshored to a “development factory” (“industrialization” was another frequently heard term, but that is another story).

This did not pan out as planned, for a number of obvious and maybe not so obvious reasons:

  • Architects in that company often are programmers that are either totally out of touch with current developments, or clearly less than decent programmers, or aren’t even programmers at all. IMNSHO an architect must have years of programming experience and must be a really good programmer with clear ideas on what kind of programming style promotes high software quality.
  • Estimates where done independently by the architecture and the development team. Since both teams had different ideas about how the software would be designed and because these ideas never got synchronized the overall estimate often was the total of planned work for substantially different approaches.
  • The architects had no real influence on the programmers. If concepts were not liked the development team simply priced them out of range (“if we do it like this (solution that we don’t like), it will cost 30% more”). Project management did not have the necessary insight to call shenanigans or to understand and act on long term consequences.
  • When architects and programmers are separate persons a huge amount of information must be transferred in the form of papers, talks, and meetings. It is much more natural and efficient to let the senior developers, possibly with some guidance, develop the architecture, and then let them move on to programming as the project continues.
  • Developers in India are not just “coders”, if that management idea of “low level programmers” would exist. They can and want to do architectural work, too. Intelligent programmers will resist to micro-management on the code level.
  • The separation felt and worked like contracting development out to an external, untouchable company. Estimates had to be accepted like carved in stone; risk surcharges, profit margins, and baseline costs where added, and there was no direct talk to the programmers. Code reviews weren’t even on the agenda.
  • And – the whole thing just does not work out financially. The plan was to specify everything down to a pretty low level and then let the cheap “code drones” take over. The problem: You spend 50% of the time or more on expensive experts working out a detailed specification and then try to get your money back by executing the last 50% or less with cheap labor. And then you find that instead of ten programmers you need fourteen plus two group supervisors plus one off-site manager to get the same job done, and your customer is not willing to deal with documents written in English. So much for comparing hourly rates by dividing one through the other and drawing the wrong conclusions.

As you might have guessed, the split between architecture and development has been reversed after a year of pain and suffering, and surely a lot of money and enthusiasm lost.

Is There a Job Called “Coding”?

“Management has announced that project management and application design will be done locally while coding will be done offshore.”

This announcement conveyes a number of messages.

The tone implies that coding essentially is some type of basic work. The thinking has been all done; now the results have to be written out in full and typed into a terminal, just like entering data from a fax or letter. Unless application design is done to a very fine level of detail, writing source code requires a lot of intellectual work to convert common language specifications into a running program.

The announcement implies, too, that coding is some kind of low level work. The architect has designed the building. Now the building company takes over, and while the construction of foundation, walls, and roof requires specific skills that an architect might not have it is quite clear there is a difference in the attributed value of work, both intellectually and financially. Writing source code requires very specific knowledge of ever changing APIs and frameworks. Apart from that, software architecture and implementation never are as independent as planning and building a house. While the latter is a pretty tried and true standard affair the former means solving a new problem with new means almost every time.

Since the company employs business engineers that capture requirements and produce a specification, architects that design the internal structure, and developers that write the software, “coding” must be what developers do, and coding is going abroad. Not too happy a perspective for “coders”, whose value has been downgraded while being informed they will be made redundant. The offshore “coders” probably don’t see themselves as data entry personnel, either. In example, I found Indian programmers at least as capable (and ambitioned) as their local counterparts.

The offshoring of “coding” work encourages management to relabel developers as architects, which might be what they are – or not. Often, the following questions are never answered: What does an architect typically do? What qualification must an architect have? Does the company provide formal training, or are architects simply being appointed? This non-definition of what an architect is leads to the employment of architects who never have been doing any serious programming, which in my professional opinion is a sine qua non prerequisite.

Management does not quite understand what their software developers do when they talk about about “architecture” (“planning the system down to the details”) and “coding” (“typing in source code”), especially in the context of offshoring. Of course development work can be split up like that. But then architecture would comprise 80% of the effort, and not much could be saved by getting 20% of the work done at low cost. Additionally, problems and insights during implementation often prompt an adaptation or change of architecture, requiring a more iterative approach than the waterfall modell “design here, code overseas” provides.

Going Offshore – Things to Keep in Mind

One of my clients decided to offshore development work. The idea is that high level, well paid work – maintaining direct contact with the customer, capturing requirements, specifying and designing the application – gets done locally while the coding gets done offshore for cheap.

This didn’t quite work out as planned, for reasons that were not too difficult to anticipate. The scenario described above touches on a number of issues that I would like to address in a series of blogs.

The anticipated subjects:

  • “High level work” – What separates high level from low level work? Why is high level (= high cost) work not offshored as well?
  • Separation of architecture and development – Does this provide benefits? Improve quality? See “Breaking Up Architecture and Development“.
  • Going offshore to reduce development cost – How much cheaper is offshore labor really? What additonal costs are incurred? See “Comparing Work by Cost Only“.
  • “Coding” – Is there a job called “coding”? What does it consist off? What happens to the onshore “coders”? See “Is There a Job Called Coding?“.
  • Ethical aspects – What are the implications of producing offshore in low wage areas of the world and selling the product in high price markets? What does it mean to the current workforce?
  • Prerequisites – What kind of projects are suitable for offshoring? What processes should be in place before going offshore is attempted? See “Prerequisites for Offshoring“.
  • Economical aspects – Are there other, better ways to reduce development cost? What does “better” mean in this context? See “Comparing Work by Cost Only“.

What does that have to do with Software Entropy? Software quality gets influenced by many factors, and the longer I work in the field the more I recognize that most problems in software development aren’t technical. Management decisions have a huge impact, and going offshore is one of them.