Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Protecting your software investment

Chris Auld and Mark Johnson | July 17, 2008
Here are some ideas for ensuring that you're not left holding a can of dated spaghetti code.

Maintain a virtual machine capable of building your application. This might be a new one for even the best and most cautious of readers. Much of the development that we do at Intergen is done in virtual machines. The luxury of a virtual machine is that it can easily be copied onto a portable hard drive and stored securely for access later on. By taking this approach, you ensure that you have always got the ability to simply re-compile your application reliably and deploy it. This is a godsend for those 'minor' changes that might come up four years after the system has been forgotten about. Without this VM you will often end up paying a vendor much more to set up a development and build environment than you actually pay them to make the change.

Clarify with your vendor who owns the IP. Different vendors will have different policies on this. It's the eternal balancing game for services companies to ensure that they meet the clients' needs while still protecting their own innovation. At a minimum you must insist on a non-exclusive, non-transferable licence to both the source code and binary code for anything that is custom developed for you. Ensure that your licence explicitly allows for the source code to be provided to another vendor so they can maintain your solution.

Documentation. Provided all of the above have been followed, then a lack of documentation will not be fatal. If we have the source code and any referenced libraries we can maintain any solution... for a price. Documentation will significantly reduce the costs of ongoing maintenance.

It is, of course, a balancing act a little like buying an insurance policy. Do I want to spend the money documenting now (pay some premiums) so that I can have a lower cost maintenance option later (receive payout on a claim). The following documentation is particularly useful: architecture diagrams (What are the various components and how do they bolt together?); deployment diagrams (Where are the various pieces of the application running?); and source code comments.

Please encourage your vendors, staff and anyone else with write permission to your source tree to adequately document their code. The concept of "self documenting code" just doesn't cut it.

Maintain, maintain, maintain. Even where clients have been diligent at the outset to follow most, or even all, of our rules, they often let themselves down in the time dimension. Specifically they do not keep all of the above up-to-date. We end up coming in four years later and, sure, they've got everything we listed above for version 1.0 of the application ... problem is, the business is running version 3.5.


Previous Page  1  2  3  Next Page 

Sign up for Computerworld eNewsletters.