Conrad Weisert, September 4, 2010
©Information Disciplines, Inc.
NOTE: This document may be circulated or quoted from freely,
as long as the copyright credit is included.
We keep hearing sad tales of the end products of outsourced software development. The programs work, but they're so disorganized and sloppily coded that our own programmers can't maintain them and we have to call the contractor back every time we need an enhancement or a simple bug correction.
That shouldn't happen, of course, but it's at least as common today as it was two decades ago.
Many contracts for software development ignore issues of code quality altogether. The customer organization may naïvely assume that the vendor, an organization of experienced professionals, will deliver code of professional quality.1 The vendor may assume that its own staff, recruited from prestigious university computer science programs, will turn out high-quality work, or the vendor may actually hope to lock the customer into dependency for follow-on work.
Whatever the fault and the motivation, the customer will pay and the relationship between the two organizations will suffer.
Every medium or large organization that develops software, either for itself or for outside customers, should have well-defined written programming standards. They don't have to be self-contained; if a textbook or a public web site contains guidance that our organization embraces, then our in-house standards can simply refer or link to that source for sections of its own standards and methodology.
Therefore, if you're a prospective customer negotiating with a software development organization, you should
| Always ask to see the vendor's programming standards. |
An established, highly professional software developer will be pleased that you asked and will be proud to show you his or her organization's methodology. But sometimes, the vendor will offer excuses.
One common rather feeble excuse is: "We always follow our customer's standards." Unless you're a very small organization with no internal I.T. capability, your unhesitating reply to that should be: "Great! Here they are!" Then make sure the contract specifies compliance and frequent review and verification.
An even sillier excuse is that their methodology is proprietary, the alleged foundation for their superior competitive performance. But they were already planning to deliver the end product to you, so you'd eventually beccome well aware of their coding and documentation practices, anyway.
A zealous salesman might try to convince you that their top-notch staff is so superbly qualified that they don't need rigid standards. That would be a good time to ask to see actual work samples produced by the specific people they're proposing for your contract.
If you discover or suspect that a company that's in the contract software development business has no in-house standards and methodology, that's a strong negative indication. It would take a hefty bunch of offsetting positive factors to persuade me to engage an outsourcing programming shop that hadn't bothered to establish its own rules.
If you elect to give a contract to an organization that has no written standards or whose standards are inadequate, then you should insist that the contract programmers follow your organization's standards, wholly or in part. The contract should make this obligation clear along with the process for reviewing and approving results.
If you're a small organization that doesn't have its own methodology, then consider:
Because of the huge body of available material the latter strategy is not a huge undertaking. It can probably be done in a half day, leaving your organization with between 4 and 12 pages of material that your own staff and future contractors will use to enhance the quality of their work and may extend2 to meet future needs.
1—That doesn't apply, of course, to body shop
contracts where the programmer will work on the customer's site under the
customer's detailed supervision.
2—The essence of continuous process
improvement a central practice in enlightened software development
organizations.
Last modified September 5, 2010
Return to IDI home page
Management articles
Project management material.