As a parent to a young kid, nights out are pretty rare. But every now and then, my daughter's "Auntie Ellen" will throw us a bone and watch our daughter overnight so we can hit the town. We're very grateful, of course, but more often than not, our daughter returns home in full-on crazy mode. We can never be entirely sure the reasons - apparently, much like the Las Vegas ads, "What Happens at Auntie Ellen's, Stays at Auntie Ellens" - but we suspect the crazies were brought on by free-flowing sugar binges and a very late bedtime.
Luckily, sugar highs and sleep deprivation in a kid whose childcare was "outsourced" to one of her favorite aunts are pretty easy to remedy. The same cannot be said, however, for faulty software builds that were outsourced to an offshore team.
Indeed, "off-shoring" has its pitfalls, which often stem not necessarily from a deficiency in education or inexperience in software development, but rather, from fundamental cultural differences. A July blog from ITexico entitled, "Preparation is key to outsourcing software product development," offers some astute observations to help here. For one, the blog suggests recognizing and addressing differences in language, traditions, values and beliefs before embarking on an offshoring relationship. Organizational differences should also be addressed, as companies in many other countries have a more hierarchical structure than those in the United States, contributing to delays in decision-making and product development.
Still, even the most thorough preparation cannot always ensure the best result. Without an on-site company advocate to manage a software build project, software quality is often at risk anyhow, leading to security issues or years of that expensive headache known as technical debt.
And quality is not the only casualty. Lacking visibility into the workflow itself, there's no way to tell how the software is being built. For example, is the team of outsourcers building unnecessarily complicated or sloppy software? Are they coding in circles and therefore dragging out the project? What the heck is really going on? The bottom line here is that outsourced teams must be held accountable for their deliverables, which is only possible if they can be managed directly and their output can be measured objectively.
Despite these concerns, today's economy requires that companies in every industry work hard to stay competitive, and off-shoring presents a cost-savings draw that is simply too powerful to ignore. In fact, companies using off-shoring as a business strategy can typically expect a net savings of 40 percent to 60 percent. So, caught between the need to save the almighty dollar and requirements for a top-quality software product, what's a company to do?
Thankfully, help is here in the form of static software analysis. The next-best thing to hands-on management, static analysis provides the visibility critical to catching code imperfections in preproduction phase, before the application is deployed and causes costly and inconvenient outages (like the RIM/BlackBerry debacle earlier this month) or compromises security.
The aforementioned blog also pointed out toward the end that "off-shoring is not offloading." I suspect this means that taking a hands-off approach to managing an offshore outsourcing project (by relying on SLAs, for example) and expecting a high-quality output is not only unrealistic, it's also unfair. Rather, close management — or, even better, increased visibility into the project using static software analysis — is critical to achieve the desired result.
As for me, I won't be installing a Nanny Cam for more "visibility" into those visits with Auntie Ellen anytime soon. After all, for all Auntie Ellen as done for us she has earned the right to a little mischief.