On Silly Patent Advice

January 30, 2007

I’ve been in the throes of some patent idiocies recently and, while I won’t comment on that (too bad, it’s funny but I don’t want to poke fun at troll layers, they’re just too easy of a target…), I’m prompted to bring on the subject after reading how Microsoft backpedaled on some patent. I also read Michael Kölling account of the story.

One thing that Kölling clearly doesn’t know is that, at Microsoft, developers are actively requested not to check prior art and other patents. So, in his case, even if management was aware of the prior art, the engineers may have moved ahead and filled for a patent unknowingly of even the existence of Kölling. If the spec was written by the Program Manager with no reference to Kölling and since devs can do stuff independently of PMs (they don’t report to each other and notoriously distrust each other), it’s entirely possible.

This “don’t read” policy is a really weird counter common sense piece of advice. The reasoning is one of those lawyer’s logic that states that, since infringing on something knowingly is worse than unknowingly, working consciously in ignoring things makes you less exposed to liability. Certainly, the fact that fines can be 3 times higher if you knew you are infringing rather than just infringing unknowingly is sort of making sense of the advice.

This might be good lawyer thinking but it’s really going against common sense and, more than likely, the intent of the law. The patent law doesn’t specify how you are supposed to do your work but it certainly assumes you do it with all the competence “commonly used in the art”. Getting to know other engineers work is part of this. So making an effort to ignoring this work is a way to game the system by adopting a counter to common sense attitude. Not convinced? Consider this.

When I lived in Jordan, I was scared by the way drivers crossed intersections: they honked and purposefully looked in front of them and left when engaging in an intersection. That despite the fact that the right of way is on the right hand! This seems highly stupid (and dangerous). The driver to who I made the remark explained to me that, in case of a collision, your liability is less if you can explain that you actually didn’t see the car on your right hand. So, in order to lower his liability, he was only glancing right and pretending not to see a right hand car coming (he certainly could see it and would stop for a fast or determined driver but his gesture was emphatic enough that the driver in the other car could see he was looking the other way).

If you think this is stupid, consider that the logic behind it is similar to the “don’t read” policy served to developers in all major software shop. It’s like saying: if having eyes makes you liable, poke them or, at least, blindfold you. Pretend you can’t read or you’re too busy for this. Playing dumb can save you. This is pushing “Ignorance is bliss” into unethical corner. Accidental ignorance can be forgiven, practising it is evil.

I think judges should simply stop giving inventors a break on ignorance when finding out is easy. Ignoring a patent (in particular when filing one…) shouldn’t be treated differently from infringing it. The USPTO patent corpus is easily browsable now so such excuse makes no sense. Ignoring papers published only in, say, russian in an obscure publication and never quoted anywhere can be understood. Ignoring a landmark paper shouldn’t. It should be considered as gross incompetence. Akin to an architect not knowing recent finding in building material engineering: do you think that an architect could plead ignorance convincingly if a bridge he builds collapse because he ignored well known material limitation? The legal difference is that architects are licensed while software engineers are not (though that could be the problem and is a contentious issue treated here and there…).

So basically I’m advocating to stop using this 3 to 1 differential when fining companies for infringment: there’ll be no incentive for looking “left” when crossing the road.

I also think that the USPTO should charge companies extra when a patent is sent back for further review: for each patent the reviewer finds that is within the invention domain and that is not discussed by the inventor, the USPTO would charge some fee. The USPTO would have an incentive to do a good job and, more importantly, the companies would have an incentive to let the inventors do a thorough research and due diligence prior filing a patent. No more “don’t read patents” sillyness.

This would have some nice consequences:

  • less “silly” patents being filed
  • a less backlogged USPTO office
  • better informed engineers (this can only be good for the industry…)

It will also put the patent system back on track with its original purpose: make inventions public so that others can improve on them or create new ones… or pay their license fees…


How programming is like sex

January 9, 2007

We’re starting to see quite a bit of bytes getting thrown after Scott Rosenberg’s Dreaming in Code. I’ll certainly have other opportunities to talk about that book once I read it in details (I only perused a copy so far and I do recommend it, and not just because Scott’s a great guy) and, likely, get asked by commentators here my take on this or that aspect of Chandler’s story.

In the meantime, I read Scott’s interview in CIO Insight and can’t help but lift that quote: “in so many books about making technology, you’d get to the point where people actually start creating the software and then it would be kind of like the sex scene in an old movie: They would just skip it, cut to the next morning, cut to the marketing team getting ready to ship the product.”

Wow! Sex as a metaphor for Writing software. Hmmm… Not that inadequate may be, since, like sex, writing software:

  • requires a tremendous up stream effort for often disappointing results
  • everybody professes deep knowledge of it but no one really knows anything about it
  • passed success is no guarantee for future success
  • real experts are somewhat creppy
  • you have more opinions on the subject than facts
  • everybody thinks he (or she) is doing it right and everybody else is doing it wrong
  • leave you open to serious issues if done without caution
  • can easily turn into a 24 by 7 obsession
  • has a high productivity peak late at night
  • we’re all too impatient to do what it takes to make it really right
  • at some point, you got to “ship it” even if it’s not perfect
  • in the end, it’s really a miracle that we can get it done at all…

New Year Resolutions…

January 6, 2007

I haven’t written down a set of New Year resolutions really and I certainly would’t share personal ones here if I had but I think I can make 2 public:

  • Ship it!
  • Get people to use it!

it being of course the Cosmo/Chandler combo (that I’ll call Chandler here under for convenience).

After all these years of development we have waaay more code and stuff to show than any start up would wish to have. Some of it might already be over designed or over engineered. The most important thing right now is to get a decent group of people (real ones, not just OSAF “dogfooders”) to tinker with the thing and give us feedback. It’s clear to me that it’s
time for a community of users to emerge and give us some guidance on where they’d like this thing to go, which problem they are trying to solve with it.

It’s not that we don’t know what to do. Our Wikis, mailing list, Bugzilla are chock full of ideas. All good and interesting. We even have dreamed users (personas) and build scenarios and use cases… and we can continue to do that till the end of time.

But code that doesn’t get used is pointless and too frustrating to work on (for me at least). After a while, I feel I’m just spinning my wheel and my creativity far being freed by the absence of real users burden actually fades: nothing better than a real life scenario, a real user with a real problem to really kick my pants and get me going.

So, yes, 2007 will be the year where people are going to start using Chandler. That’s my resolution for the year.