Freigeben über


"Custom Code" - What we really mean...

The term "Custom Code" gets thrown around quite a bit, and the default perspective most people have can be not quite accurate... so lets clarify this simply:

"Custom Code" (noun) - Any functionality integrated into a product that does not have committed resources and schedule for support and updates.

I'm willing to change this viewpoint if I hear a compelling argument for amendment, but so far I think this relatively broad definition is relatively accurate. It basically boils down to a simple concept: If there is a 3rd party that you can rely on for prompt ongoing updates (bug fixes and security patches) to the product, and that you can direct contact for support on questions, issues, problems, or recommendations, then it is NOT custom code. Anything that doesn't meet these specs is (or at least needs to be treated as if it is) custom code.

To be clear, when we use the term "Custom Code", we're referring to any functionality that you must take direct ownership of for fixes or updates, or that you must compensate for because fixes and updates are not available. While you may understand clearly that this means any code you've written yourself, it also means that any open source code (i.e., Codeplex) solutions, software developed specifically to your business needs (non-packaged, custom developed functionality) by a 3rd party, and even packaged features/software from a 3rd party that no longer exists must be treated as "custom code". The outcome of all of these situations is that if you need an enhancements, changes, fixes, or updates to that functionality, you must either directly write it, or pay someone else to write it for you. There is no real fall-back position or party that can serve as your "go to" resource for that functionality... no one that can back you up if something isn't meeting your needs.

Lets use some examples:

  • You purchase a packaged product from a software development company that enhances the functionality of your SharePoint environment. Is that custom code? NO, as long as the vendor maintains a commitment to updates and patches (within the given version, perhaps), then you don't have to write or maintain the code yourself. (You do have to regularly check for and apply updates though.)
  • You download a SharePoint solution package from Codeplex. Is that custom code? YES. Maybe you didn't write it, but you have no guarantee that the code is well written or will be updated after that initial download of the WSP. You're dependent on an unknown 3rd party to provide updates and fixes if/when they have time, and there is no resource that can serve as an "expert" in that functionality. Further, you don't have any guarantee that the project owner isn't going to simply delete the download location for that WSP, eliminating your ability to even refer to ongoing discussions on issues found. In this situation, you should download not only the WSP itself, but also perform all of the recommended development process you would otherwise need to follow if you had written it yourself. Specifically, code reviews, test deployments, and code-level version control system storage.
  • You download some "free" functionality from a well respected vendor. Is that custom code? NO... but it might be someday. Granted, your ability to get the source code may be limited... but you clearly don't have a support contract with the vendor... so as long as you're willing to pay for incident based support, and as long as the company exists for you to request that support, you should be fine. If, however, something unfortunate happens to that company or its product, you may find yourself in the uncomfortable position of having to compensate for code you're now dependent on but is sub-optimal.

In the end, the separation is simple: If you can rely on someone to maintain that functionality for you and serve as an expert in it, you don't need to treat that code as "custom code" and you can feel reasonably comfortable testing and deploying the functionality (assuming it doesn't create other supportability issues in your environment, or the 3rd party resource is willing to take ownership of any issues caused by its code).

If however, you have no one to rely on but yourself... congratulations... you've got custom code... regardless of how you acquired it. Plan accordingly!