Chad Michael is a software engineer, primarily working in the Java realm. He believes in doing things the right way, which means following engineering principles of procedure, documentation and design. On a more specific level, he is a proponent of test-driven, agile software development practices, design patterns, automated unit tests and constant refactoring. Above all else, he's committed to a mode of constant learning that sustains his engagement in his profession. He's also the author of two books: Struts 2 in Action and the SCMAD Exam Guide. Chad is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

The Hidden Cost of Outsourcing Software: Software Intelligence

  • submit to reddit
As everyone knows, time in the world of software passes very quickly when compared to other aspects of business.  So, in the last ten years, the way many companies handle their software needs has seen drastic change.  In particular, many companies and organizations that would have, in the last century, employed their own software engineers, now outsource the creation of software to external sources.  I'm not talking about India or Russia, though that could very well be the case -- I'm just talking about having someone else do the work because the costs of doing it in-house are too high.

This is not news.  It's a fact of life.  The cash-wise savings are undeniable.  But I'm not here for, nor interested in, a discussion of the economics of outsourcing software.  I'm here to discuss something a little less tangible.  I think the speed of change in the world of software has outstripped our ability to develop sound correspondent business practices.  Being young enough to have only worked as a member of small teams that do the outsourced work of larger companies, I have given a lot of thought to the odd relationship between us and them.  Yes, us and them is how I think of it.  There are the occasional "partnership" moments, but typically it feels more like us and them.  And it's quite clear that the us and them relationship is not doing anyone any good.

I have come to realize that many companies, in the rush to eliminate their in-house software engineers, have failed to recognize that they may have inadvertently thrown the baby out with the bathwater.  The bathwater is the cost of full time employees.  Again, no one denies that you can lower costs of developing software by outsourcing.  There is, however, the baby to think of.  With in-house software engineers, your assets are twofold, at least.  First, they produce software for you.  With outsourcing, that aspect is covered perfectly well by the external team.  But the second, and perhaps most important, asset you have in an in-house software team is Software Intelligence.  This is Intelligence with a capital I, as in the CIA.  With an in-house software team, you have folks that know about software and can advise you on how various types of software, various trends in software, and all those software related buzzwords might play a role in your company's business model.  By using their irreplaceable knowledge of both your company's business and software they can help guide you towards the software decisions that will best realize the business goals of your company.

But now that you've eliminated these folks, who can you expect to provide this advice to your decision makers.  One might suggest, as I am suggesting, that you seek advice from those external teams that you have hired to build the software.  They have replaced one aspect of your internal team, why not ask them to replace both aspects?  It's hard to envision this from the us and them context.  So, why does it have to be us and them?  It's mostly economics I'm afraid.  

When the company buying the software negotiates the deal with the seller of the software, it seems that the primary thing on everyone's mind is the total cost.  For the customer, it's critical to get the software for a price that doesn't break the budget; keep in mind that it was cost that motivated them to outsource in the first place.  For the seller, it's critical to get paid enough to make a profit; estimating software costs is not easy, and the demands to produce an upfront not-to-exceed estimate can be stressful on many levels.  It's hard not to see this relationship as something of a poker match at best, and, at worst, openly adversarial.

So, in this environment, it's hard to conceive of an "advisory" capacity for these external teams.  Of course, the purchasing company could hire an external "consultant" to advise, but that seems a bit redundant.  The solution is probably a lot simpler than one realizes.  The money-based us and them scenario arises from the fact that everyone is only thinking about the software product and how much it's production and delivery should cost.  If you start thinking of the external team as a provider of two services -- software production AND Software Intelligence -- then you've already shifted the focus of the relationship away from buyer and seller.  If the external software team believes that their ability to provide Software Intelligence for the outsourcing company will contribute to a long and prosperous relationship for both sides, then you're that much closer to a true partnership.  Besides, asking for advice always changes a relationship for the better.    

While this may be hard to envision, there are few good options.  When you got rid of the in-house software team, your company may have lost all of it's Software Intelligence.  If you don't recover that Intelligence from somewhere, then it's hard to imagine that you can make the right software decisions.  If you are still thinking about the money . . . then you've missed the point.
Published at DZone with permission of Chad Davis, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jonathan Fisher replied on Mon, 2012/05/14 - 7:25pm

A lot of businesses seperate management and development. Management doesn't understand while things like newer frameworks or how open source project XYZ could be leveraged to reduce costs... as a consequence, they simply overrule any developer concerns. At this point, the in-house "software counsel" is ignored, so they gain no Intelligence, so it makes sense to outsource.

Old school software management treats developers as factorties and software as a black box. Modern software companies by contrast have realized that putting engineering in management leads to huge cost savings.

Andrey Panasyuk replied on Mon, 2012/05/21 - 4:15am

I personally think that it's all about the way you choose the right people into the offshore team. You should be really careful but the result is worth it.

I'm doing offshore development for about 8 years already and worked with a whole bunch of different people on different sides. And I didn't see that the attitude towards the "Product" differs greatly between offshore and on-site developers. It mostly depends on the person you hire. I wouldn't say that the average level of skills is greater for the on-site developers based on my experience. In any case good people cost good money.

One more benefit here is that in many cases offshore developers participated in the whole bunch of different projects and have a much broader vision on what's going on in the technology and can propose way better solutions for the customer needs. From my experience, the developers who spent years working on the same project can really learn a lot from the newcomers.

It's quite frequent to have 25-28 year old team members here. And the age is not the least factor in the learning and ability to create an interesting product. It's just a different mindset. However this can come together with a lack of experience.

In general I think the truth is somewhere in between. In many cases it's reasonable to bring new blood in the project but you need to be really careful when you try to give all of the work to the offshore team.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.