Isn’t it funny how Americans always assume that we can still get something for nothing? Have we learned nothing from the Dot Com fiascos and the corporate meltdowns of the past decade? Surely we have, but we make the same mistakes repeatedly.
We also have the false impression that a universal quality standard exists that governs all software development regardless of location. We further believe that we’re saving money in spite of poor quality products and services.
Quality is not ubiquitous. There is no standard by which all programmers design and code. Product quality must take the highest priority in any development shop. If quality isn’t the highest priority for these development teams, their low cost is moot.
The opening statement from N. Venkat Venkatraman’s, 2004 article “Offshoring without Guilt” in the MIT Sloan Management Review asserts:
“The new hot topic being debated in board-rooms, at meetings and in Internet discussion groups is ‘offshoring,’ the practice among U.S. and European companies of migrating business processes overseas to India, the Philippines, Ireland, China and elsewhere to lower costs without significantly sacrificing quality.”
If you believe that you can get the same quality offshore, but at a dramatically lower price, you’re enjoying what’s commonly referred to as a “hallucination.” Enjoy the short-lived euphoria because a heaping dose of reality will soon replace it. And, you’d better have a large bottle of antacid handy to soothe the burning reflux of missed deadlines, the bile-flavored taste of insecure code, and the unquenchable gas bubbles of employee turnover.
Of course, it is cheaper, so that might temporarily take a little of the fire out of the pit of your stomach. That is until you have to have a one-on-one with your client about the project delays due to rewrites and fixes. Suddenly, Mr. Venkatraman’s words echo in your throbbing head. “Lower costs without significantly sacrificing quality.” Notice that he didn’t say, “without sacrificing any quality.”
Does this mean that you can’t locate quality development and support outside the hallowed U.S. borders? No, but it means that you should use caution when you make assumptions about quality. In fact, you should ask for references and “google” a few for yourself to investigate any negative commentary or feedback regarding your potential partner.
So, now that we’ve established a baseline of “all development is not created equally well,” we can move forward with locating high-quality, well-crafted applications using Nearshore resources. But, how do you measure software development quality? The following list offers five basic application quality guidelines.
1. Error Checking – Does the application sufficiently check for input errors from the end user?
2. SQL Injection Prevention – Are methods in place that check for and remove possible SQL injection attacks for database-backed applications?
3. Are applications protected by secure connectivity using certificates and encrypted sessions?
4. Is there clear documentation for the project, applications, and architecture?
5. Is the code written to some standard so that it can be supported, maintained, updated, and upgraded by another team, if necessary?
If these five basic questions aren’t met with “Yes,” then you should move on to another development group or Nearshore partner. Your goal isn’t to have the application produced for the least number of dollars possible but to produce the best results for the money. Applications that aren’t secure put you, end users, and the development firms at risk.
End users risk losing personal data to poorly designed applications and hacked databases. You and your development team stand to lose credibility over application quality issues. It’s easier to repair a damaged application or a compromised database than it is to repair a tarnished reputation.
The following list of Nearshore development Do’s and Don’ts will help guide you to the best available resources for your project.
1. Don’t assume universal development quality.
2. Ask for references and check the references.
3. Perform an online search for any complaints or problems.
4. Insist on a high standard of development quality.
5. Focus on the product, not the price.
6. Ask the right questions about application quality.
Nearshore development companies want your business. Ones that have been in business for a few years have worked out most of the quality issues that likely plagued them early on in their growth stage. Additionally, they’ll answer your questions without hesitation and have a long list of satisfied customer and high-profile projects in their portfolios. Startups, however, can be risky if neither the owners nor the employees have enough years of experience from which to draw.
Simply because you choose to use Nearshore resources for your development projects doesn’t mean you have to accept less than first-rate workmanship. On the contrary, you should insist on it. Abandon the idea of not “significantly” sacrificing quality. Instead, seek out a provider that will make sure you don’t have to sacrifice any quality.
Ken Hess is a technical analyst, author, and consultant. He writes regularly for Linux Magazine and ServerWatch.
I absolutely agree… the difficulty is that we sometimes think in single values and not multiple (labor arbitrage, quality, cohesive operation, expand ability, etc.). One point, relating to programming standards… there are standards as a part of both ISO & IEEE but they are designed as frameworks, not a cook book. Because programming is more an art form first a pragmatic science (like engineering) it tends to have a bit of latitude that is allowed. This does not however permit due professional care from being exercised, both by the buyer as well as the provider. Just one of many elements that requires close examination as a part of the due diligence process.