Why I Was Late To Work

I’ve been working almost entirely from home since March, mostly so that I can be home in case Amy needs something and Cindy is unavailable due to her sleep issues. On most days I also get to save an hour otherwise spent commuting, but that’s usually soaked up by extra time “at work” or in other ways. Once such other way happened this morning. We had some heavy rain and thunderstorms, which seemed to have subsided when we heard a *crack* from outside. We’re all too familiar with that sound from last October’s storm, so we immediately went to the windows to see which tree or limb had fallen where. It turned out to be a pretty big one, effectively blocking our street in both directions. Our street happens to be a popular commuter shortcut, and during rush hour often has a line of cars half a mile long. It’s also heavily used by emergency vehicles getting across town or over to the next town, so a blockage is serious business.

First thing to do was call 911 and let them know of the issue. Next was to put on some shoes and see if I could clear at least one lane. This limb was big enough that I seriously doubted I could move it very far myself, but I figured if people saw me trying then someone else might come out to lend a hand. That would have been in their own best interest, after all. Sure enough, two guys immediately got out of their cars to help. Between the three of us we were able to get the limb swung around enough to clear one lane. Then a miracle happened. A guy with a big truck pulled out of the queue, got out, and pulled out a tow strap. He immediately set about wrapping it around the tree while I directed traffic. Naturally, I let the two guys who had helped get on their way first. When Truck Guy was ready we pulled the limb further around, and then the two of us rolled it enough so that both lanes were free. Then he went on his way as well.

The police showed up just after the action concluded. That’s not a knock against them; they clearly had plenty of other things to deal with. I went out and talked to the officer who was there, who said they’d get DPW to take a look at it. When I got out of my shower, I was totally unsurprised to see guys with chainsaws and a wood chipper across the street, and everything’s cleared away as I write this – a little over an hour after the branch fell. What I think stands out about this is that four total strangers spontaneously got together to deal with a problem that wasn’t really theirs (the tree might be in front of my house but technically it’s on town land right next to the street), in a way that was completely complementary to the contributions of the local government, then the whole setup just dissolved when it was no longer needed. It’s like a flash mob with a purpose.

All in all, this wasn’t quite as dramatic as saving the drunk guy in the water on Long Beach Island, but it was certainly a good jolt of adrenaline to get my day started. I think my boss will understand why I’m answering email a bit later than usual this morning.

Not Even Bad

One of the big news items today is that NuoDB has patented its approach to distributed databases. Jim Starkey and friends have always been prone to make grandiose claims, so it’s not too surprising to hear “clean sheet re-invention of the relational database” and such. It’s a bit more surprising that GigaOm’s Barb Darrow saw fit to repeat such claims uncritically, and throw in the “superstar” bit in what amounts to a far more valuable bit of PR than NuoDB could ever purchase above the table. Just check the Twitter stream for “nuodb patent” to see how valuable that phrasing must be to them. But that’s not what I’m really here to talk about.

At first I had trouble finding the text of the patent, but that must have been the result of my own searching error because when Justin Sheehy pointed me at the number for the granted patent (other sources had only given the application number) I was able to pull it up right away. That number is 8,224,860 by the way, but Google shows the wrong thing and and USPTO is link-unfriendly. Part of my reaction was also amazement that such a thing could be granted. You see, the idea of a patent is that the author is given protection from copycats in return for a public description that will allow the invention to be recreated by someone else after the patent expires, so that the idea is not lost in the trade-secret dustbin of history. The standard for this description is usually expressed as detail sufficient for one of “ordinary skill in the art” to implement it. That’s vague as hell, but it defines an interesting boundary. If even someone with below ordinary skill can implement an idea, then it’s probably too obvious to be patented. If more than ordinary skill is required to fill in the gaps left in the description, then the description is inadequate to fulfill the grantee’s side of the patent bargain.

The thing about the NuoDB patent is that such broad claims should be backed up by a proportionally comprehensive description, but the actual description is way over on the sketchy side. Some people have already said that the patent shouldn’t be allowed on the basis of its obviousness, but that misses the point about the difference between claims and descriptions in a patent. Many people will tell you that it’s the claims that matter, and that you can mostly ignore the description. I’ve told people that myself. However, it’s not entirely accurate. A more precise way to put it is that the claims are the enforceable part. As the thing that the applicant seeks to protect, the claims are the part that matter once the patent is granted. The description, as the thing the applicant offers in return, is supposed to affect whether the patent office should accept the deal. It’s payment, in the sense that not providing it is like failing to pay the filing fee. You don’t pay the price, you don’t get the product. So what are we to make of something like this?

This invention generally relates to database management systems. More specifically this invention relates a method and apparatus for implementing a multi-user, elastic, on-demand, distributed relational database management system characterized atomicity, performance and scalability.

Databases are now judged by a standard that defines ACID properties, namely: atomicity, consistency, isolation and durability. Atomicity guarantees that all transaction tasks will be completed in their entireties. Consistency assures is that only valid data is written to the database. Isolation assures that other operations cannot access or “see” data in an intermediate state during a transaction. Durability assures that once a transaction has been processed successfully, it cannot be undone.

So far, so good. Now, how does the described “method and apparatus” actually achieve these goals? Remember, patents are supposed to describe methods, not just outcomes. For example, how does the described system provide consistency for a transaction that spans many objects – i.e. a complex join? They don’t say. No, really. Search for “join” in the document and you’ll find lots of stuff about nodes joining the cluster, but nothing about joins as the term is used in the database world. There is some description of consistency issues (search for the unexplained term “atom skew” – at least the terminology is novel) and even some boilerplate about replication messages being exchanged, but there’s no description e.g. of how the complex ordering relationships among these messages are retained. Likewise there’s nothing in there about how to prevent or ameliorate the storms of update traffic that certain requests can generate with this approach, or what happens when there’s a failure in the middle, etc. You can repeat the same exercise with respect to durability, or other well known problems, and find all sorts of huge gaps in such a description.

Now, I don’t expect the description in a patent to be a full-blown spec describing the software in just-short-of-code detail (though that has been done in some of my applications and I gather that it’s commonplace). For all I know Jim and Co. might actually have made some breakthroughs, and might legitimately have something worth protecting, but none of that innovation is actually reflected in the patent as written. I’m criticizing the document, not the underlying work. The problem is that the omissions in that document represent the actual mechanisms that are supposed to be described. The gaps that I’ve mentioned are the actual hard problems, the things where truly patentable ideas might actually exist. Nobody could implement what NuoDB is claiming without recreating – or improving upon – the innovations that the accompanying description should explain. The patent is supposed to be for a novel “method and apparatus” but what we actually have is a laundry list of standard approaches and standard problems. The bragging about how quickly the patent was approved and how no prior art was found is, in reality, almost an admission that the examiner couldn’t find anything concrete or specific enough to search for. How do you search without terms? That should have stopped the application right there, with a demand for more information, before the government agreed to enclose so much of the intellectual commons for practically nothing in return.

That brings me back to the title. This isn’t a bad patent. The system has been set up with rules that allow bad patents. What I’m saying is that this particular patent doesn’t even conform to those rules. It doesn’t even meet the usual standard for becoming a bad patent, so “not even bad” fits rather well.