Software Code Quality: Dotting the I’s and Crossing the T’s & C’s

RFG believes software vendor contracts fail to meet the software quality requirements essential for enterprises to run business- and mission-critical applications. IT executives, along with corporate counsel, should scrutinize vendor contracts and negotiate either up front or at contract renewal for the incorporation of “quality of code” language. In addition, IT executives should challenge vendor claims that force customers to purchase software “as is,” without the proper warranties in place. Moreover, before signing on the dotted line, IT executives should negotiate for amenities, penalties, and other protective clauses that mitigate enterprise risk and exposure.

Business Imperatives:

• There are two primary reasons why enterprises today are experiencing problems with the code quality of packaged application suites. The first is that these vendors typically test their products incompletely, resulting in customers essentially becoming unsuspecting beta testers. The second reason is that the suite is often designed and coded to satisfy a single customer (or customer sub-segment), and therefore is not generalized sufficiently to meet the individual needs of each customer. To protect themselves from poor testing of general release versions of software products, IT executives should negotiate for terms within the contract to limit their exposure.
• Today, hardware, middleware, and software vendors are beginning to understand that to become trusted partners to their customers, they will need to share in the risk/reward. At present, vendors are not required to guarantee the integrity and quality of their code. However, in the future, they should be held accountable if software code errors are directly responsible for downtime or failures, which interrupt their customers’ business operations. IT executives should request that a senior vendor executive (e.g., Executive Vice President) certifies that the software code being delivered has passed internal quality tests. This includes, but is not limited to, the code being stable and containing no known errors that could render the application inaccessible, severely limited, or accessible, but malfunctioning.
• Contract reviews can be as stimulating as watching paint dry on the wall. The language is virtually incomprehensible and the challenge to understand its implications can be daunting. This is compounded by the fact that it is incumbent upon the customer to ensure the appropriate software quality of code language is included. IT executives should ensure that they, corporate counsel, and/or other qualified parties scrutinize contract terms and conditions (Ts & Cs) and oblige the software vendor to comply with reasonable modifications.

This Research Note will provide some guidelines to mitigate risk and remedy certain software code quality exposures.

Software Contract Ts & Cs: “It’s all legal-eze to me.”

While it is the desire of some enterprises to beta test vendor products, it is incumbent upon those IT executives who do not wish to do so to protect themselves and their organizations from becoming such. This can be accomplished in the agreement or contract with terms that limit the customer’s exposure. Below are some generic examples of Ts and Cs that IT executives, along with corporate counsel, should review and consider negotiating and re-adapting for inclusion in vendor software contracts.

Commercially reasonable.

IT executives should be wary of these types of clauses. This is because they often indicate that the vendor will determine the schedule by which it will “fix” a software bug or dispatch people to work on a problemeven if the customer is unable to conduct business. While there is no way to determine how long it takes to fix a bug, the level of effort to fix one can vary significantly by vendor. Therefore, IT executives must ensure that the vendor adheres to a schedule, which is pre-determined and both time and resource based. In addition, if the vendor, by doing so, must add additional employees or work outside normal business hours, the vendor should not only comply, but also assume sole responsibility for all costs. However, if the problem is the result of a customer delay, error, and/or negligence, and is not the fault of the vendor, then both parties should agree on an equitable adjustment to the costs to compensate the vendor.

Software shall comply with all specifications.

IT executives should not accept language from a software vendor that simply asserts “the software shall comply with all specifications.” RFG believes this is too broad a statement and instead, IT executives should get a service level agreement (SLA) or commitment from the vendor. The commitment or SLA should ensure that if there are any code quality issues, the vendor is responsible for fixing them at its expense and within a prescribed period of time that corresponds to the customer’s requirements.

In addition, IT executives should also negotiate for a threshold of code quality problems so that when the threshold number is reached, the contract is in breach. For example, the software should have no Severity One or Two problems in a given period of time that is mutually agreed to by both the customer and the vendor. Severity Three problems or software bugs could be calculated by percentage of lines of code using a process such as Six Sigma (i.e., no more than 3.4 software bugs per million lines of code). While it is not reasonable, today, to expect software companies to meet Six Sigma standards, the customer and vendor should negotiate a realistic error rate. If these terms are exceeded, then the contract can be considered in breach. The customer should then be able to cancel the agreement and be entitled to all (or a major portion) of their monies back. Moreover, IT executives should be able, under the contract, to seek punitive damages against the vendor if software code quality issues caused interruption of business.

Tangible deliverables.

IT executives should ensure a software agreement or contract reflects the following criteria regarding tangible deliverables that the vendor is required to supply the customer. These can include, but are not limited to, hardware (should any have been included in the contract), materials, software media, and supplies.

• Deliverables should be new and of good quality and therefore usable for their intended purposes (e.g., tapes or diskettes can be read from the tape drive, etc.)
• Deliverables should be free from design defects unless the customer provided instructions for the manufacture thereof and the customer design was flawed.
• Deliverables should be safe and suitable for their intended purposes.
• Deliverables should be at the latest agreed-to release and include any and all fixes.
• Deliverables should be free from any “viruses,” back doors, or other code that exposes the company to outside tampering, data corruption, code corruption, code locks, or any other actions that interfere with the company’s normal activities and processing.
• Regarding hardware, some application software vendors will perform sizing for the required hardware and peripherals, but then in the contract, disclaim the sizing warranty. IT executives should ensure that back up and redundancy have been included as well as room for growth, and they should hold the vendor accountable to some level of accuracy. For example, an acceptable variation might be 20 percent, plus or minus, but certainly not 600 percent. If the hardware is undersized or if the vendor failed to inform the customer of additional required hardware, middleware, and/or software, then it is the responsibility of the vendor to remediate this situation to the client’s satisfaction.

IT executives must also ensure that any and all of the deliverables conform to the descriptions, drawings, instructions, requirements, and specifications of the software agreement or contract. IT executives must also make certain that the contract reflects the fact that they have the right to reject any of the deliverables as well as cancel all or any unperformed part of the agreement if they deem that a breach has occurred. It should be incumbent, then, on the vendor, at the customer’s option, to do the following.

• Promptly perform corrective action including re-performing the services or correcting the nonconforming or defective deliverables, at the vendor’s sole expense.
• Refund or credit the price of all services and deliverables rejected or cancelled by the customer. In this case, the vendor is also responsible for all risks and expenses involved in the examining, handling, repacking, storing, transporting, and/or unpacking, (inbound and outbound) of any the deliverables that are rejected by the customer. The contract must also reflect that the vendor must reimburse the customer for those expenses.

Warranty breach.

Should there be a breach in the above-mentioned warranties, it is incumbent upon the vendor, at its expense, to take prompt and all necessary actions to correct the breach. These can include, but are not limited to, performing any services (e.g., installation/implementation) again to provide the customer with the result that was originally expected and agreed to. IT executives should provide prior written approval for the vendor to take corrective action and the vendor should use “best efforts” to perform the remediation. If the vendor is at fault regarding the breach of any warranties, then the vendor should be responsible for the costs it incurs and any expenses incurred by the customer.

Should a problem with the vendor software occur and it is determined by the customer that this constitutes a breach, then the responsible IT executive must take the following actions. He/she should ensure they have provided the vendor with notice and within a reasonable time period after they are made aware of the breach. Should the vendor fail to respond and/or promptly correct or take steps to correct the problem, the IT executive may have to intervene and take corrective actions on his/her own. For example, should an emergency situation exist (e.g., the company cannot conduct business), and the vendor has not/cannot respond, then the IT executive may need to internally remediate the problem or obtain outside assistance.

In this case, the vendor is responsible for reimbursing the customer for all expenses incurred in performing the corrective action, including any cost of replacement materials, services, supplies, and tools. IT executives, however, should ensure that the contract reflects the fact that any corrective actions the customer must undertake do not void the vendor warranty and do not result in the waiver of any other rights or remedies. This is important because some vendor agreements/contracts stipulate that if the customer modifies the software or source code, the warranty becomes null and void. In a case in which the customer has no other choice because business has been interrupted and the vendor has failed to respond, the vendor should still uphold the warranty for the remainder of the period in which it is in effect.

It should be noted that the above recommendations should be treated as guidelines as they are not all-inclusive and are not meant to be represented as legal instruments. IT executives should consult with corporate counsel, as well as other knowledgeable parties, before incorporating any or all components into a software agreement or contract, so that the legal department can review and adjust the language accordingly.

RFG believes many vendor software contracts cleverly sidestep the issue of accountability for software quality requirements and remediation for buggy code. IT executives who have implemented or are implementing vendor software, and especially those who expect to remain with their current vendor or vendors for a significant period of time, must remain engaged with these vendors. IT executives should negotiate either up front or at contract renewal for “quality of code” clauses and/or an SLA.

RFG analyst Maria DeGiglio wrote this Research Note. Interested readers should contact RFG Client Services to arrange further discussion or an interview with Ms. DeGiglio.