First to invent vs. file conflicts could be used to raise the bar on obviousness.

Obviousness is surprisingly difficult to determine because some of the best and most brilliant ideas are also very simple ideas that seem obvious only in retrospect. So the patent office is deliberately reluctant to interpret the obviousness constraint too rigorously.

Recently, the US has switched from awarding priority of similar patents to the first one to be filed instead of the first to be invented. Since there is often a very long delay from filing to patent award, during which filers must not publicly disclose their idea, priority becomes an issue more frequently than one might expect.

It seems obvious to me that instead of struggling with who has priority, the patent office should simply look at two similar patents being filed at about the same time as a failure of the obviousness test because, clearly, two different practitioners of the art came up with similar solutions to a problem. So both patents and any similar future filings should be rejected as obvious.

This doctrine would have disallowed a lot of patents in the past including the light bulb and telephone, which, while revolutionary were being investigated by several inventors who came up with similar solutions and even filed within hours of each other!

“In the beginning, there was nothing. Then God said, 'Let there be light'... and there was still nothing but, you could see it." :: Groucho Marx

Actual coding is the smallest part of modern software development not just because of all the meetings agile techniques like Scrum require, but also because we're expected to support the code we write instead of just writing it in isolation, tossing it over the wall and expecting some other sucker to maintain it. The theory is that if the developers have to support the code themselves, then they'll pay more attention to quality, reliability, stability and other factors that improve maintainability.

Of course other related work like design, documentation, code review, testing, deployment, performance analysis and so on contribute to making actual coding a small part of the whole process.

Jobs with 20 hour seat-of-the-pants hackathon sessions in some low level language that gets dumped straight to production are increasingly rare.

The question is whether all of this overhead is worth the effort? If done right, maybe all of this turns coding into professional software engineering that can reliably produce high quality solutions to business needs... or maybe it's just another failed attempt, like waterfall, that adds all sorts of useless overhead to fool management into thinking they have some sort of control.

So far, I'm thinking that it may actually help, but the jury's out and I think it's highly dependent on your organization and individual team. Even great ideas can be need up by poor implementation.

More specifically, it's an attempt to apply Fitts law to computer user interaction. Tog has an article on the thinking behind this.

More from Karen Sandler... IT Conversations has an interesting podcast featuring Karen Sandler talking about her efforts to get source code for her defibrillator.

Um, all you need to do to get your email from one email system to another is forward your messages as attachments form one to the other.

In fact, the defunct ZOË email archive server uses this technique to import email... of course, it automatically files all of the attachments as separate emails, so it makes it easy. Other clients may require more work.

Along with some interesting revelations, the interview of James Whittaker about his book, How Google Tests Software, included some discussion about effective crowd sourcing of software. Part of his argument is that even the best test engineers are going to miss things that end users find easily, so one way to leverage this is to make it as easy as possible for end users to provide high quality bug reports. He also has a lot of interesting things to say about scaling the testing process.

I was a little disappointed that, for a topic that mentions JavaFX, there hasn't been any significant discussion about JavaFX at all so far.

I'm admittedly not a UI developer, but, I've been playing with ScalaFX and looking at GroovyFX and seeing a lot to like (See JavaFX 2.0 and Scala like Milk and Cookies). Combining this stuff with some of the ideas from Morphic and we could get some really compelling UI's that would be hard to do in a browser even with HTML5.

That's why languages like Scala are so appealing.

Sure, there's no silver bullet to automagically solve all parallel programming problems, but languages like Scala have features like Parallel Collections libraries, functional programming and Parallel Domain Specific Languages that can abstract enough of the problems of parallel programming away that journeyman programmers have a decent chance of being able to work effectively with multiple cores.

Argh! There's an error with my post... McCollum got the idea from Feynman. Basically that antimatter is just regular matter going backwards in time from the big crunch. So, not a glorious case of Sci-Fi presaging science, but a case of Sci-Fi rehashing interesting science.

Sorry folks. Bad post and reply to my own post.

Actually, there's an error with my post (accidentally AC)... McCollum got the idea from Feynman. Basically that antimatter is just regular matter going backwards in time from the big crunch. So, not a glorious case of Sci-Fi presaging science, but a case of Sci-Fi rehashing interesting science.

Wow! So Michael McCollum got it right in the Makers series where the difference between matter and anti-matter ends up being a primary plot point... which I won't spoil, but maybe these researchers should peak ahead to the last chapter of the second book, Procyon's Promise, to see what the answer is ;-)

Sorry for accidental duplicate AC post.

If that were true, then they could just use OpenID to accomplish the same goal.

Many sites that use OpenID for logins make it easy by providing pre-configured FaceBook, Google, and Yahoo buttons along with an 'Other' button for those who want to provide their own OpenID URL. For example, StackExchange sites provide five buttons and a more link on their login page. This makes it trivially easy for most people, possible for most of the rest and provides alternatives for geeks and contrarians.

I use spamgourmet.com for disposable email addresses.

Among other things, spamgourmet lets you set the number of messages that can be sent, so it can be useful for things like placing an order where you need to register, get an email with a link to validate your email address and then get an order confirmation and a few tracking status emails, but then stop accepting anything after that.

It doesn't catch as many bad actors as I thought it would, but when they do misbehave, it's kind of cool to see the number of deleted messages that never filled my inbox.

They also have it set up so that it you can reply to messages routed through spamgourmet without giving away your real email address. There's also an alternate domain so that when you're dealing with an actual human being they won't be freaked out by an email address that has the work "spam" in it.

The Scala community has tried to move the problem into a more practical realm by adding things like parallel collections, DSL's to abstract out the problem for specific applications and the Akka Project for simpler concurrency.

Most of the parallel programming discussion I've seen is very complicated and not likely to appeal to those who have to do practical day-to-day business projects. By pushing the abstractions up a level, I think the Scala folks have made parallel programming more accessible for the average developer.

Ref: Parallel Collections video.