Patent Center Delay—Good Start, or More Entrenched, Magical Thinking?

The U.S. Patent and Trademark Office’s (USPTO’s) delay in retiring EFS-Web and Patent Center is welcome news. But my fear is the announcement could be just another display of the magical thinking, disregard of engineering and legal process, and deafness to stakeholder input that has been the hallmark of the USPTO’s software processes.

Perspective

I know a little about implementing complex software systems. I was a teaching assistant for the software engineering course at the University of Michigan in the 1980s. I was a very successful engineer for Hewlett-Packard in the 1990s (my boss always commented on the long line outside my office). I was HP’s representative to a standards committee for parallel processing on multiprocessor machines. I was invited to lecture on compiler construction at M.I.T.

First, anyone with any software experience knows that in any complex system, for every ten bugs that get fixed, two new ones are exposed—in a well-designed system. In a system that neglected design techniques for correctness and robustness, like (to all externally-visible appearances) Patent Center, the ratio is closer to five for ten. In letters of November 1 and November 4 from a group of Intellectual Property Professionals to the Office of Management and Budget/Office of Information and Regulatory Affairs and to the Commerce Inspector General, we pointed out that the USPTO has been adding multiple bugs per week. The USPTO’s Electronic Business Center (EBC) has been telling callers for weeks that they acknowledge Patent Center doesn’t work and recommending EFS-Web as the fallback. The USPTO’s implicit expectation that things will be substantially improved in a week reveals either a remarkable degree of magical thinking or pervasive disinformation.

The Inspector General criticized the USPTO’s poor estimating, poor software management, and nearly sixfold cost overruns in two reports: USPTO Needs to Improve Its Cost Estimating, Scheduling, and Agile Practices to Timely Retire Legacy Systems and USPTO Should Improve Acquisition Planning and Vendor Performance Management to Prevent Schedule Delays and Unnecessary Costs Related to the SDI-NG Contract. If expenditures continue at the rate discussed in these reports, the USPTO has spent $1 billion on this software project. Every engineer knows you have to build in a factor of three for schedule slips—but six? To all appearances, no lessons have been absorbed, and no reforms implemented. It’s insanity to keep doing the same things the same way and expect a different outcome. In a week.

The First Step is Admitting the Problem

Second, the USPTO’s processes are fundamentally broken. To take one example, it’s abundantly clear that the USPTO’s testing regime is far below professional standards. When the same bug gets fixed, comes back, gets fixed, and comes back a third time, all within about three months, the inescapable inference is complete breakdown of the USPTO’s quality engineering. As another example, the USPTO claims it has shifted to a “new way of working” using agile methods. Agile requires increased rigor in validation and testing. Instead, to all appearances, the USPTO has dialed its rigor down over the last few months, in order to stick to an artificial deadline. And sponsorship (the only thing the Director’s blog commits to fixing) is only one of 100 or so problems. Problems that aren’t acknowledged can’t get fixed. This morning, the Patent Center page announces a large number of corrections for the next four business days—leaving no apparent time for testing. No competent software manager would try to jam this much into a week—managing to an unrealistic deadline instead of to a quality target is the surest way to miss both objectives. Six months could be conceivable, if Director Vidal orders a recommitment to quality first and instructs that deadlines will be set based on a sound readiness review, not the objective-backwards approach of the last few months. Improbable, but conceivable. Without radical process change and personnel reassignments, as recommended by the Inspector General, net forward movement will never occur. Pretending this can be done in a week is just asking for trouble.

Third, the thing that’s missing from all the USPTO’s analysis is an acknowledgement that Patent Center’s bugs impose costs on users. The only costs discussed in the Director’s blog article are the costs the USPTO bears for the delay. Not a word even acknowledges the bugs, let alone their cost. Because bugs are unpredictable and require on-the-fly diagnosis and work-around, each one costs a lot. And the mere existence of some bugs means we users have to be doubly careful to double check for errors in everything else—once you know the sidewalk is icy, you have to walk slowly. As long as the bug rate remains where it is today, those costs to the public far outweigh the costs to the agency—we estimate well over 10-to-1. The Paperwork Reduction Act requires the USPTO to consider those costs to the public. 5 C.F.R. § 1320.5(d)(1)(iii). The Office’s refusal to account for costs to the public isn’t just rude and narcissistic, it’s illegal. Neglecting half of the cost picture is incompetent decision-making.

Fourth, the USPTO says they’re going to upstaff the EBC. Wait a minute—how does that improve the software? Isn’t that a concession that the software is not ready for prime time? The USPTO is clearly thrashing—do something, anything, no matter how irrelevant, to divert attention from the process and decisions that created the problem.

The best the USPTO can come up with is non sequiturs. For example, “Since its launch six years ago, we’ve rigorously tested Patent Center and made improvements based on your feedback.” Past effort at “improvements” is not current state. Six-year-olds get trophies for effort, but not software. It’s raw amateurism to confuse the first derivative of a variable of interest with the variable of interest. (And the only person that can claim that the USPTO’s testing is “rigorous” is someone with zero experience in a professional software environment and that doesn’t use Patent Center to try to get work done.) The Office has never said either of the only two things that matter: (a) features and reliability of Patent Center have been designed and assessed using metrics that matter to users (not the developers’ uninformed views of what they think might be important to users), and (b) A meaningful and rigorous status review based on user input concluded that Patent Center is useful and reliable on those metrics. Nowhere has the USPTO said those two things, because neither is true.

No Shortcuts in Software

Finally, it’s time to be honest with the public. The schedule clearly hasn’t been driven by a sound readiness review with objective input from the user community. What’s the real schedule driver?

Patent Center might be ready in six months if the USPTO stops telling the public what the USPTO thinks is good for them, and instead starts listening, considering costs to users, and adopting high-reliability processes and useful evaluation and prediction methods. In software engineering, there are no shortcuts. The only path to success is rigorous process and care. Patent Center will not be ready until magical thinking is walked out the door. As Richard Feynman wrote, “For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled.”

More complete explanations can be found in the following letters (several of which were authored by me):

November 4, 2023

November 1, 2023

October 31, 2023

October 30, 2023

October 16, 2023

October 9, 2023

September 29, 2023

Image Source: Deposit Photos
Image ID: 6496641
Copyright: stuartmiles