Outing my source

I know, it’s been a while.  Here’s an older topic that I’ve been thinking about lately — and that’s dealing with outsourced code.

Outsourcing development is attractive for its context-based lower development costs and faster turnaround (I say “context-based”, because often times if you relieved an in-house group of its non-productive responsibilities and allowed it to compete on an equal footing, you’d get the same level of cost and quality).  Unfortunately, too many outsourced projects don’t take post-delivery activities into consideration.  Often the contracts are written with the focus on functionality and time-to-completion without corresponding rigor being applied to code maintainability and compatibility with existing maintenance processes.

It’s a real shame when the cost savings associated with the development and delivery are obliterated by cost increases in maintenance and operation.  The challenge is to make sure that the contract stipulates adherence to internal standards which will support internal takeover of the developed code.

Here are some questions to ask when you get a chance to provide input to an outsourced development contract:

  1. Will the code follow our development standards, naming conventions, packaging rules?  If not, why not?  If not, will we have to re-work the code upon delivery?
  2. Can the code be checked into our source-code control system when we get it?  If not, why not?
  3. Can the code be compiled, built and made installable by our local build system?
  4. Will the code use third party software that we’re not familiar with?  Will it require separate licensing?  Will we be able to get training on it?
  5. Who will do integration, system and/or scalability testing?
  6. Who generates the test data and who owns that testing data?
  7. Is the software built to support regression and/or scenario testing?  Will it run in our local testing environment?

In the end, it becomes your code and your responsibility.  It should be held to the same standards as your internal code development — and that shouldn’t be a problem.

One Response to “Outing my source”

  1. J S Hawksworth Says:

    Thanks for those oh so pertinent but seldom asked questions.
    Since source control is vital, and clear allocation of responsibilities are too, your 7 points constitute a potted reality check on outsourced (or sourced from anywhere) code.

    Thanks for these, which I will E-Mail to myself at work, and then use to make the managers think twice.

    A result indeed!

Leave a Reply

Posting code can be a pain. To make sure your code doesn't get eaten, you may want to pre-format it first by using HTML Encoder