Patently bogus

There’s a story in the feedback section of the latest New Scientist about a “lazy inventor trap”; it restored my faith in the stupidity of much of today’s patent processes. No surprise, the story’s hidden behind a paywall.

Why worry when you’ve got Google. I entered the patent application number and there it was. You can read the patent here. But I’ll save you the trouble.

It’s a patent for some form of hybrid between image capture and document, somewhere in the copier and fax space. But that’s not important.

What is important is this clause, which occurs six inches into the front page of the claim:

9. The method of providing user interface displays in an image forming apparatus which is really a bogus claim included amongst real claims, and which should be removed before filing; wherein the claim is included to determine if the inventor actually read the claims and the inventor should instruct the attorneys to remove the claim.

What is important is that the clause was not buried in the small print, it was at the start of the claim.

What is important is that the inventor was meant to have taken the bogus clause out.

What is important is that the inventor didn’t. Nor did his attorney. Nor did the Patent Office. Nor did anyone reading the patest for the last two years.

Just goes to show.

Do patents actually get read?

We have patent spam, and it’s gotten worse. Discovery of prior art is not easy. People game the system.  There are frivolous patents, spurious ones, defensive ones and frankly offensive ones.

Time for a change.

Doc on VRM

Doc’s posted on why he wants VRM. As he says: “This is our problem. We’re the ones in the best position to fix it.” So now I have to find a way to be at the Internet Identity Workshop in a few weeks’ time. It’s a bugbear of mine as well.

Building for the present — all the time

If you’ve been waiting for Parts 3 and 4 of the Filmmaking and Software Development post-series, my profuse apologies. I’m still reading through some of the references people suggested I follow up, and I feel I shouldn’t complete the posts until I’ve read them all. Otherwise I might as well not ask for comments and feedback….]

But in the meantime, I can’t resist moving from Filmmaking to Netflix, while keeping in the Agile space. Especially given the serendipitous bloglike way I got to the Netflix story. I was reading Chris Messina, one of my regular reads, when I came across his post on Photo Matt’s new look. That in turn led me to this story on The Freedom of Fast Iterations, a Joshua Porter post on UIE.com. If you have the time, it’s worth wandering over to Joshua’s blog, Bokardo, where he looks at social web design and related issues.

Back to Joshua’s Netflix post/interview. Read it for yourself, it’s a must for critics of agile. There are some wonderful quotes there, examples below:

  • “We make a lot of this stuff up as we go along,” the lead designer said. Everyone in the group laughed until he continued, “I’m serious. We don’t assume anything works and we don’t like to make predictions without real-world tests. Predictions color our thinking. So, we continually make this up as we go along, keeping what works and throwing away what doesn’t. We’ve found that about 90% of it doesn’t work.”
  • The designers at Netflix told us they try out many new features with every site iteration to keep pace with the rapidly changing landscape of the Web, as well as their customers’ increasing comfort with the current site. Much of what they do try doesn’t survive to the next iteration.So how often does Netflix update its site? Every 2 weeks. Every 2 weeks they make significant changes. They understand that some of the changes will work, but most won’t.
  • At first, this sounds like a frustrating design constraint. In talking with the team, we realized that it doesn’t frustrate them at all. Instead, it frees them up to be flexible and adaptive, so they can react effectively to customer needs. As a result, they don’t deal with the many “when we redesign” issues that so many of us deal with in the design world. They’re building for the present — all the time.

I love those quotes.

  • Building for the present — all the time. If I wanted a mantra for fast iteration, that would be it.
  • It frees them up to be flexible and adaptive, so that they can react effectively to customer needs. Anything that makes you more responsive to customer needs is a must-do nowadays.
  • We don’t assume anything works and we don’t like to make predictions without real-world tests. As an economist-turned-accidental-technologist, you don’t know how happy I am to see those words.

The post goes on to enumerate some benefits of fast iteration:

  • Fail Fast
  • More Experimentation
  • Learn Quickly
  • Provide Continuing Interest
  • Reduced Risk

They’re worth a read, but I guess most of you have come across similar lists before. What is unusual, however, is the list that follows, headlined Side Effects:

  • Culture Change
  • Design Determinism
  • You’re Either With Us

These are bang on the money. Read it, read the whole post and see for yourself.