When writing about the troubles Apple had last week during their v2.0 launch, I reminded about some of the load challenges we had with the MCAT system under heavy volume, and, of all things, software patents. should point out that the The following is a brief post that I wrote last semester after giving a presentation on the Amazon One Click patent case in a class on Internet policy. It never quite made it up, so I am sharing it now.

(I should point out that the load issues I talk about here were resolved with a rather popular queuing system that we build for the MCAT registration system that managed load throughout the system. I loved that project, and a great lessons learned about performance services oriented architecture! Okay, enough geek talk – carry on…)

I got to work at 6:30 am the day after a class presentation on the Amazon “One Click” legal issue, and walked into what we loving call “the war room.” It is exactly what you would expect. Computers are everywhere, monitors, projectors, and a conference phone I am determined to paint red. This, however, was not a military operation, although pretending sometimes helps us do a better job. This was a launch day for the MCAT software. We were opening over 50,000 testing seats, and war or not, pre-med students fighting for their future always results in blood.

By 11am the system had opened, the seats had been released, and the system was screaming in pain. This is actually fairly common. As a peer said when trying to explain the situation to a member of the business team, “Even the most perfect system will die when it exceeds normal performance capacity by 10,000%”

From a software development perspective, when you need to improve performance, you start hunting down your bottlenecks. For the MCAT, however, there is a catch. MCAT uses a lot of 3rd party vendors, and is developed across a services oriented architecture. While this is the future of software architecture, it also means that we don’t have control over the entire bottle. The red phone is for vendors to call and report problems (if they happen to see them), and the screens are to detect problems across the entire system (because with this number of monitors, we are pretty good at seeing the predicting problems, just like tornadoes, before the full onslaught). To put it simply, our load shoots up for several hours a year, and with that much volume the bottle (necks and all) simply explodes under the pressure.

I once asked a project manager a fairly obvious question: When all we as developers can do is spend years programming defensively against poor 3rd party systems, why didn’t we just amend our contracts to demand a higher level of service? If only life were that easy. The project manager’s answer was simple: “Jed, those contracts took three years to finalize,” he explained, “and developers are cheaper than lawyers.”

I share this story (while omitting many technical details for the sake of those same lawyers) because it shares a lot of similarities to how I feel about the software patents I have been researching, and the Amazon “One Click” issue in particular. On one hand, I am sympathetic to all software developers who are trying to make a better product but are barred by legal variables that can’t quite be capture in a programmer’s algorithmic way of thinking. (I have been there!) On the other hand, it is this pride for an innovative product, well developed, that is most deserving of protection and patents are a compelling form of insurance. (And I have been here too!)

Back in the war room, during a lull in the logs (being broadcast by open source software, not to mention our entire application and server stack that also runs on open source software), I turned to two Enterprise Architects who were there to help out needed. With my Amazon presentation fresh on my mind, I asked them the question “Should we eliminate software patents?” Despite the glow of open source illuminating the war room, and the fact that if our third party vendors were more “open” we might not be in the war room to begin with, they both simultaneously answered “No.”

It is hard to not look at software as a new digital land grab. Without sufficient governance to manage these contested claims, however, software patents do more damage than good. I can’t say that we should eliminate them either. After all, why head west if there is no promise of fortune? The issue gets even more severe when we consider the entire “business process patent” issue of which software patents are a part. For today, I can only hope for a panacea combination of opposition period (during which patent claims can be contested by the practicing community) and a shortened patent length for some types of software and business process patents would help. Will the twelve judges reviewing re: Bilski agree with me? We will have to wait and find out.