Custom Software - Part II

Last column I started the discussion of custom software development agreements. Undoubtedly, they're one of the most difficult types of contracts for technology 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 are some tests which specify particular operations and the length of time they should take to complete. Here, it's important to also specify the hardware on which you will be running 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.

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, delivery of documentation, and completion of acceptance testing 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 problem is that your vendor considers their source code to be a valuable trade secret that they don't want to reveal. You feel 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 things happen like the developer going bankrupt.

My aim now is to make you aware of the issue, but I must also must 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 scratches 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.

Contract Drafting

While I'm on the subject of contract drafting, I can't help but comment on lawyers' contract drafting habits.

Why do lawyers insist on using language that's as meaningful to today's English as quill pens are to word processing? I mean, what exactly does "Witnesseth" add to an agreement? Oh yes, let's not forget a list of factual recitals that all begin with "Whereas."

How about if we all agreed not to use words and phrases like "hereto," "hereinafter," "thereto," and "in witness whereof." I happen to think that the quality of our writing would inevitably improve.

My all time favorite is not contract language, but rather is letter language. What mind originally conceived of, "Enclosed herewith please find the following." What's wrong with, "I am enclosing the following?"

Just because it's old and traditional doesn't make it good. You can sound like a lawyer without using stilted and archaic language. In fact, you might even sound like you can write.

You can find a TechLaw archive at: www.EComputerLaw.com.