Trade Agreements as Software

Submission to Foreign Affairs, Defence and Trade on the Trans-Pacific Partnership Agreement 31 March 2016 - Ian Wells

8 Lessons from the IT industry to Improve Quality of TPPA

Presented to the subcommittee to Foreign Affairs, Defence and Trade on the Trans-Pacific Partnership Agreement  31 March 2016, Christchurch, New Zealand

Ian Wells

Introduction

I appreciate the opportunity to address you.  I speak to you, not as a TPPA trade expert, but as a regular family man living in Christchurch, as an immigrant who loves New Zealand, as a resident who has strong respect for New Zealand’s  democracy and  heritage, and as an IT professional.

Based on my professional experience, I view the TPPA, not just as a legal document, but as an item of information. The software industry, especially in the last 5 years,  has learnt many lessons about quality and has developed effective ways of managing, distributing, testing and improving the quality of information systems. Some of these lessons could be applied to the TPPA, even at this late stage.

Lesson 1. I encourage this subcommittee set up mechanism to track TPPA bugs.

The TPPA, like any information system,  has bugs, including serious ones. Good information system processes define, record, track and fix bugs. IT companies employ testers trained in Context-driven testers, because they are expert at finding and communicating bugs that threaten the value of a product.

Lesson 2. I encourage this subcommittee to identify and monitor interfaces so bugs can be tracked and the TPPA meets the needs of New Zealanders.

The most serious bugs are likely to do with externalities ( interfaces). The TPPA seems to be internally consistent but not consistent with externalities. Good information systems will continually confirm that interfaces to externalities “work”. The environment around TPPA is guaranteed to change.  For example, Al Gore identified 6  inter-related near future trends: economic globalization, instantaneous communication, international relations, demography and capitalism, human health and biotechnology, and natural resources and climate change. I am concerned the TPPA has not, and could not, anticipate how these trends will play out in the near future. The TPPA could impede our country’s ability to deal, in time, with issues like climate change and biodiversity.

Lesson 3. Although this recommendation is 10 years too late, I encourage the subcommittee to increase visibility of the TPPA processes.

The quality of the information system is improved by increasing transparency. This is why Open Source can have so few bugs. More eyes improve the chance of finding bugs before the system is implemented. TPPA was developed in secret.

Lesson 4. Although this recommendation is 10 years late, I encourage this subcommittee to validate the TPPA with New Zealanders.

Information systems are best developed with continual validation from clients, not just sponsors. The sponsors of TPPA, based on the lobbying statistics, are corporate interests to increase and control trade. The clients of TPPA are New Zealanders. There has been no a priori validation from clients. Validation is most efficiently done before implementation.

Lesson 5. I encourage this subcommittee to implement this agreement gradually, tracking bugs, applying lessons learned, and correcting bugs before implementing the next stage.

Incremental, frequent, small releases of information systems will result in a higher quality product than a single specification and a single release. The TPPA was “specified” over 10 years and is being released all at once.

Lesson 6. I encourage this subcommittee to implement a process to allow New Zealanders to submit bugs and have them fixed rapidly and transparently.  

Because any information system will exist in an environment that changes, use a process that is built for adaptability.  The  TPPA has no  mechanism to fix bugs in the text itself, and no process to fix bugs that impact the clients of the document. And to do so rapidly.

Lesson 7. I encourage the subcommittee to develop a mechanism to predict the chance of failure, based on knowledge of bugs and behaviours of complex systems, and use this information before implementing.

Information systems can fail completely because they have too many bugs. The larger the information system, the more bugs it will have and the more likely it is to fail in operation. The TPPA is 6,000 pages long. Statistically it has a high chance of failing.   

Lesson 8: I encourage the subcommittee to build in testing into the document  using tests written in the language of the client, for the next agreement - too late for TPPA   Good software designs are testable, in the language of the clients, not the language of the programmers or sponsors.  Ensure the product has testing built into the design. This allows continual, public validation through the entire process.  

In short, I recommend that the TPPA apply lessons learned from the IT industry, to improve the quality of the TPPA in meeting its objectives and meeting the needs of its clients: New Zealanders.

How the TPPA is an Information System

My professional experience is all to do with fixing quality problems of information systems.

I see both TPPA and computer systems as examples of  programmed iformation systems. Both contain coded rules that describe how we process tasks. They are both plans. It is not known how they will work until they actually run or enacted.

The  TPPA can easily be viewed as an information PRODUCT that us New Zealanders have bought. Like buying a new operating system for a computer. The sponsors seem to be the corporations and lobbyists who had the most input to the document. The “clients” of TPPA are all of us.

The reason for the analogy is there are lessons the software industry has learned that can help predict the “quality” of TPPA.

Although the  TPPA is a self-consistent document, it will have an impacts outside that self-consistency. For example, the impact on New Zealanders ability to  respond to climate change, constraining our ability of  New Zealanders to decide what are our  “digital rights”, restricting how New Zealanders can control technology insider our own vehicles, homes or bodies.

If TPPA was  a spec for a computer system, no professional would sign it off, because it breaks almost every best practice for a successful information system project. No computer company could force it users today to run unpatched Windows 98.

TPPA was “specified” in private, secret negotiations, written by representatives of corporations, with no validation from the  “clients” to be impacted by TPPA.  Because the “spec” is large (6,000 pages), frozen and has interfaces to many other systems in society and business, statistically, it must contain many “bugs”. There is indeed a “bug” resolution method for corporations through secret ISDS. There is no appeal process in the public sphere. It is not clear that the ISDS has the power to change a “bug” in the contents of the TPPA.  And there is no bug resolution for those outside the Parties involved. The whole of the TPPA is to be implemented as a single document. There is no incremental implementation with client (all clients) validation. These are all signs the TPPA information system has many bugs that cannot be corrected.

If the TPPA was released in a democratic way, it would be completely different. There would be a public input before the document was signed. There would be public debate. The process would be transparent. It would have more weight given to public interest. It would strengthen our democratic institutions not take power away from them. There would be public ways to report and fix “bugs”. There would be public accountability for its implementation.

If the TPPA was released in a IT way, it would be completely different. It would be cheaper, more adaptable  and more efficient that the current TPPA process. It would include early client validation, it would include testing all the way through, it would be released incrementally and continuously so it meets the needs of the client.

In short, the TPPA is not flexible enough and not democratic enough to meet the needs of New Zealanders. In fact, it’s rigidity and lack of concern for all clients is detrimental to the flexibility and innovation New Zealanders will need to confront the rapidly emerging challenges of the near future.

Lessons TPPA could have learned from Software

I am a person who thinks a lot about the future. By profession I am a software tester and QA manager - I test whether information systems work. I spend my professional time fixing software bugs and designing processes to prevent bugs.

Software projects, despite the best of intentions, often do not work because of too many bugs, for example Novopay. Perhaps you have overseen such software projects yourself.

Although systems are tested extensively, bugs are always (with a few very rare exceptions) found once the information system hits the real world - it is impossible to predict how a complex information system will behave, without actually using it.

Needless to say, the TPPA has bugs. These will become apparent when it is enacted.

The software industry knows the importance of defining, tracking and fixing bugs. What exactly is a TPPA bug? How many bugs are there? How are they to be fixed? How long will that take?

What is a TPPA “bug”?

A TPPA bug would be a flaw that causes an incorrect or unexpected result, or unintended behaviour.

There are various types of bugs. One is the failure to meet specification (in this case, the TPPA document). For example, failure to promote sustainable growth seems like it would be a bug. Or failure to address urgent issues of environmental protection issue.

The other category of a bug in TPPA is “unfit for purpose”. What is the purpose of TPPA? The preamble states, for example, “promote sustainable growth” and “recognize inherent right to regulate … the environment”. But also TPPA affects other aspects of our lives, for example, the TPPA is actually establishing our digital rights, before we have done so through democratic processes.

Although the TPPA may be self-consistent, it has impact on many other systems that are important to New Zealanders - for example, climate change ( is it “urgent”?), digital rights, loss of democratic decision making, impact on innovation, loss of culture due to copyright law changes, slowdown in making laws due to possible impact of TPPA, impact on government ownership, etc. Many groups are already reporting these types of bugs.  

These too are bugs based on  omission and are a result of the intentional TPPA process - in secret, a single up/down vote, written by lobbyists for multinationals, extremely complex, never voted or debated by democratic representatives.  

So any place where TPPA does not meet its goals, or is impinging negatively on other aspects of our lives,  is an “unfit for purpose” bug.

Similarities between Democracy and Software

I also wanted to say something about democracy. Democracy is also a highly evolved, information processing system, that meets citizen needs. Like modern software development processes, it includes transparency of process and continual consulting with the clients, and it provides a legislative and legal process to correct “bugs”.  The TPPA is not following best software development processes, it is bypassing our democratic processes and removing power from our democratic processes.

It is not too late to at least track how this is working for New Zealanders. It is shockingly late for our democratice leaders to relearn the lessons the software industry has learned.