The mythical "Indian man-month"

Introduction

For long, it has been established that measuring software development result cannot be reduced to a time-spent unit such as man-month. As early as in 1975, The mythical man-month became a famous book that explained this in different ways, including the mention that adding resources to a late software project could only delay it more. The book was republished in 1995, a confirmation of its accuracy, but also a proof that the necessity of -explaining this to non-software people remained fully necessary 20 years after. I have no doubt it will be necessary to keep repeating the message in 2015, as software production remains a widely misunderstood discipline among decision-makers.

A lot of people keep comparing this to the physical industry where the same component needs to be produced thousands or millions of times with the exact same process. In software, a source code is produced only once as it is immaterial and can be copied as needed at almost no cost. And still, even when comparing with industry, one should think whether a team of 10 guys with shovels would dig a hole faster and at less cost than a team of 3 guys with bulldozers. So it is not very hard to understand that each business evolves in method and tooling. Software is probably even more concerned than many other businesses, considering the technology evolution pace.

Emergence of off-shore

Still, since the emergence of the "off-shore" model in the late 1990s, the focus on hourly cost of developers has peaked without many voices in the software industry to challenge these new software production models.

The reasoning was as simple as the following most of the cost of software development is the salary of developers, as it is a time-consuming activity, which is true. So if one goes to countries where the time is less costly, it will cost less in the end. This fully neglects the importance of the methodology, in particular the interaction process with users or product management, the skills and the tooling but who cares?

At that time, the development of cost-killing methodologies, combined with the power given to purchasing departments and their basic comparison methodologies and the absence of a relevant metric to measure software production (beyond the man-month) made this reasoning the general trend in the industry, leading to what I would now call "The mythical Indian man-month syndrome", with Indian developers being of course cheaper than their western countries equivalent with higher salaries.

Despite the awareness of numerous field failures (one can read this 2004 article as an example and notice the cautiousness of the title), the trend has continued to date. To some extent, skills and part of the production methodology has of course improved in the off-shore countries, but the most important point about interaction with business users remains.

20% savings "when it works"

As the president of the R&D focus group of the AFDEL (French software vendor association), we had a session of experience sharing about off-shore. Not only were mentioned many failures, but the fact that struck me the most is that the successful projects talked about 20% savings in the end, when including all the hidden costs that were needed to make it work. And it was also mentioned that it required about 2 years of ramp-up to make it successful.

Interestingly, I found this interesting CIO magazine article that confirms this observation made as early as in 2003! This article has the merit of listing any of the costs, as well as explaining this "20% savings in the most favorable case" reality.

Understanding the harsh reality about off-shore should be no surprise, as I personally love one comment on this article:

It is very difficult for business users and IT workers residing in the same locale to work out software requirements and successfully execute a project. In fact, some statistics say that around 80% of IT projects fail to meet their goals. Now imagine moving the technical team several thousand miles away, put them on a work schedule that is completely opposite that of their end-users, give them a different native language, and give them a completely different set of cultural mores and norms. With as much sarcasm as I can muster, I must say that none of this seems intuitively likely to increase the odds of success, but it does have the "advantage" of being really cheap.

Paying a low price for something that does not fulfill your need is for sure a wrong spending!

Probably more than 100% extra costs in other cases

Now let us come back to field experience, off-shore "per se" is not the solution to the numerous challenges faced in software development. This is why we observe many failures on the field where we estimates costs being around almost the double as they should be, not only in the short term, but over the long run.

It is not the matter about whether developers are good or not in some geographies (although there are geographies with more or less skills) but mostly the nature of software development that makes it challenging to work distantly from users.

Trendy agile methodologies are smart enough to put an emphasis on the proximity of product management role. We have developed the importance of alignment in our series of post about "Measuring software development performance", that developed 5 key critical dimensions:

1. Alignment
2. Productivity
3. Quality
4. Debt minimization
5. Predictability

If the team is large, you might have a chance to run for the 80% side of the spectrum with the "scaling effect", but even so, it is quite challenging to reach it. And we have seen many customers moving back from off-shore models and now hiring local resources.

It is also worth mentioning that many failures on the field are just taboo and then perfectly explained by technical teams, taking advantage of the difficulty for decision-makers to really measure success. It is quite common in this industry and is of course exacerbated with the complexity of a distant team.

Beyond the costs

Beyond the costs, going too far with off-shore often causes:

• Skills challenges, as you may not find the best technical solutions,
• Loss of control, as you may depend on external partners that do not have the same interest as yours,
• Loss of agility, as you may require months to change even simple business requirements,
• Increased risks of various nature because of the distance, the language, the culture and sometimes even the legal or intellectual property risks.

In the end, by externalizing too much of your development, you will lose the skills to even evaluate whether you are doing well or not. One could also mention the citizenship dimension but this is not even my point here.

This is why, even if off-shore is often a failure, few people publicly admit it, leading to a significant market hypocrisy, which really contrasts with discussions experts have together when they share their experience in a face-to-face mode.

Seriously, as an informed decision-maker, would your risk losing control for an uncertain potential 20% savings?

I personally would not we have never even thought of externalizing the R&D of our software, as an example.

As we have written in a previous post, it is only with the contribution of software engineers that you can make a real long-term difference on the market, as those guys are the ones able to make some critical choices. Some choices can impact the software development cost with another order of magnitude while delivering the same value!

So make sure you keep at least some local skills, or you will expose yourself to losing control at some time in the future.

Daniel COHEN-ZARDI

SoftFluent CEO