Custom Software Development (Part II)

Last week, I started the discussion of custom software development agreements. Undoubtedly, they're one of the most difficult types of contracts for computer lawyers to write. This week, I'll complete the discussion with some additional items that you should consider in your agreements.

Performance Standards

The thing that makes computer-related contracting so difficult is that you have to write the contract so that it provides objective standards for subjective problems. Software problems are rarely as easy as "the software won't load". Hardware issues that I face in my practice are never as easy as "the computer won't turn on". These are easy and obvious problems that a lawyer fresh out of law school could handle.

The real life problems my clients have are, "The software is too slow," or "It crashes too often," or "It doesn't do what I thought it could do." To help deal with problems like this, a good software development contract includes pre-acceptance performance standards to measure the software's abilities.

A good starting point is to perform some tests that specify particular operations and the length of time they should take to complete. Here, it's important to also specify the hardware you will use to run the tests. In the best case, you specify the hardware that you'll actually be using in your operation.

In developing the test scenarios, you need to also consider "load testing," which takes into account things like the effect of having 250 employees simultaneously accessing the same network. You may find that your results are meaningless if you have one person at a time accessing the network for testing purposes but will have hundreds once the software is in use. There is no single perfect answer to this problem. You and your developer are going to have to be imaginative in creating effective load testing scenarios.

Another type of test to specify would be a "response time" test. You might input specified data and then specify how long the system should take to process the data and take you to the next screen.

If the software fails one or more of your tests, your contract should have a procedure in place for reporting the problem and requiring revisions. It should include time limits for finishing the revisions and require regular progress reports.

Warranties

After you've accepted your software, you will probably find things that aren't quite right. Here's where your warranty becomes important. A good warranty makes a distinction between mission critical failures and others of less importance. When your software won't perform a basic and essential function, your agreement should require an immediate and high level response. It should have a procedure that requires senior level developers to jump right in to fix the problem. Depending on the nature of your business and the software, this may be a 24 by 7 obligation. For example, if you're running a hotel reservation service, Monday morning at 9 a.m. isn't going to cut it if the system is down.

Other types of glitches may be less critical and may require a different type of response. Generally, you don't need to awaken (although you may want to) senior level management because an operation is taking .3 seconds longer than it should. It's probably safe to wait to Monday on that one. The point is that your warranty language must be sensitive to the differing nature and importance of problems. It should have appropriate response requirements that vary based on the problem.

The length of warranties is often a contentious issue in a negotiation. This issue is closely tied to the issue of maintenance obligations and agreements. A typical scenario might have a six-month warranty with an annual maintenance agreement at a specified fee after the initial period.

That may be fine but watch for maintenance obligations under the maintenance agreement that are narrower than the obligations under the original warranty. Be particularly sensitive to any software operations that you may not get to test during the warranty period. For example, you may have year-end operations that won't take place until after the warranty is over. If they fail at year-end, will the maintenance agreement cover the required repair or modification? The answer depends on your particular maintenance agreement's language. If you anticipate the issue, you can raise it during your negotiation and ask that the original warranty be extended in certain areas like year-end operations. I've had some success taking this position.

Year 2000 Warranties

No technology-related agreement can be considered complete without extensive Year 2000-related warranties. The warranty and related language required for Year 2000 alone is more than a page. I've seen vendors try to boil it down to a sentence, but that cannot adequately protect the buyer. Moreover, these warranties should not expire until at least 2002. This will give you plenty of time to run and test the system in the twenty-first century.

Payments

Payment is always near and dear to everybody's heart. Usually, software development contracts will call for partial payments at specified milestones. For example, you might have a certain percentage due upon execution with additional payments due at completion of preliminary testing, upon training of your personnel, at delivery of documentation, upon completion of acceptance testing and with a final payment due when "going live." From the buyer's point of view, you want to pay as little as you can up-front to make sure that the developer has plenty of incentive to complete your project quickly and properly.

Source Code

Discussion of source code is often a heated issue. "Source code" is human-readable computer language. Generally, you need the source code to modify software. A problem arises if your vendor goes bankrupt or, for whatever reason, refuses to cooperate with you if you need or want to modify or fix the software. The issue is that your vendor considers his source code to be a valuable trade secret that he doesn't want to reveal. However, you feel that you need it to protect your investment in custom software development.

Usually, the parties can agree on a source code escrow where some third party agrees to hold the source code and not release it unless certain specified events happen such as the developer's going bankrupt. My aim now is to make you aware of the issue, but I must also emphasize that this is a treacherous area with many pitfalls for the unwary. It may help if you work with one of the several reputable companies that are in the business of administering source code escrows. They can help guide you based on their experiences.

Custom software development is a complex area and even two columns barely scratch the surface. My purpose has been to give you a feel for some of the issues that arise. Do yourself a favor and move cautiously in this area. Many businesses have paid lots of money for disappointing products. Get experts on your side so that you don't end up joining that list.

I would like to acknowledge the research assistance provided by Adam Feinsilver.

Mark Grossman's online research source is Lexis-Nexis. He thanks Lexis-Nexis for their support of this column.