Auto-autos - a little less biology in the loop

What I hear at the water cooler

I recently visited the Silicon Valley Open Source Automotive meetup at HackerDojo. Ostensibly required reading ahead of the meeting was the wired article on auto-autos. You kind of have to read that one as a backgrounder, but the summary: google already has dozens of robotic cars on the road driving around with you, and they are better drivers than humans. Been that way for a while. Yeah. I was surprised too. But wake up and smell the robotic equivalent of coffee, whatever that is. (Or just watch these robots make breakfast instead.)

Anyway, had a nice chat with some knowledgeable people. Some similar opinions to what I heard from electric car junkies at CES. Consensus at the meeting was in line with the wired article concerning the timeframe for commercial availability of auto-autos - 10 years or so.

What seemed to be totally unknown was the business model. Even the little baby steps of car automation, auto-parking, nicer computing systems with heads up displays, etc. are out of reach of the average consumer due to price concerns. Actually, I can't immediately think of any future car technologies that would save money on the initial purchase price of an automobile. So although everyone seems to accept that self-driving electric-hybrid robotic cars are the future, no one has a clear grasp on the business model that will enable that future. FWIW, from what I hear, that is the consensus at all the clued in major auto makers.

What we are on the cusp of is a form of transportation with a 10X advantage over what exists (at a higher initial price). You park it anywhere, and you can let it automatically drive you. It's safer, cheaper on energy, and frees up your time. It's like having a driver pull up when you want him, and chauffer you around. With luck, an auto-auto can drop you and park itself somewhere convenient (seriously, who wants spend their time parking or paying someone to drive you). Rich people will just buy these things outright, but the rest of us need another model.

A cursory amount of research reveals that big rental car companies are already renting electric cars. Local government intervention and purchase of advanced vehicle fleets occasionally pushes clean car tech as well. Without conflating electric cars with auto-autos too much, I believe that the markets and challenges are similar for both technologies.


Spin we're likely to hear

Briefly I'll mention psychology. There is, of course, fear - range anxiety, and any other anxiety that you can whip up in people about new car technology - this will definitely kill individual purchases. Certain segments of the American market which are primarily driven by fear are ... unretrievable. Those people will buy only what they are told to. But with a 10X value advantage the rest of us will get over that fear. Interesting thought - corporations are motivated to uncover the facts behind the FUD to improve the bottom line - corporations are FUD creators, not FUD consumers! Corporations are not easily scared away from value.

The energy industry has to be considering which side to weigh in on. Oil demand destruction is not in line with oil company interests. Interests that can afford the best congresspeople money can buy. Exxon predicts 60% of cars will be gas-only, 40% hybrid, by 2040, with a negligible sprinking of fully electric vehicles. Not in line with what I've been hearing elsewhere. Interestingly, though, they expect all oil demand increases to come from the commercial sector. On the other hand, it seems at least some public utilities might stand to gain power through charging and other infrastructure. They are also fleet customers.

Finally, there is no legal framework for robots driving cars, particularly without a human in the loop. However, everyone seems to be looking the other way right now. This is where the opponents will hit hard and fast, buying congressmen like it's black friday.

Smarmy smarty-pants ill-informed theory

It seems that fleets are the current wedge by which electric vehicles and auto-autos are entering the market. And since even electric car nuts won't pop for the first auto-autos, renting from fleets makes sense, ala the carsharing models of zipcar, u-car-share, philly-car-share, hertz on-demand, etc. etc. Auto-autos actually make perfect sense for these fleets from an insurance perspective as well as an efficiency perspective, especially if the law will look the other way to driverless auto-autos.

Cab companies will love them as well. Cabbies will not. If there is any middle class left in the US in 10 or 20 years, they will probably be more likely to call an auto-auto to get to work than a cabbie.


First we replace the horse, then the rider.

We used to ride horses around. That lasted for what, 1000 years? It's still cool to own a horse and ride it around, for fun, I mean, but it's getting rare. Farming is done by robots, self-flying planes are almost there. Automatic cars are so close we can taste it. Tastes like robot.

Also see Brad Templetons stuff:

talk slides

website

We are all Agnostics now.

David Brin recently spoke at the Singularity Summit, a place where the attendees are, for the most part, transhumanists. They are there to discuss the creation of "small" gods - things just a little better than humans in some way, that will improve themselves.

I know that Mr. Brin recognizes that even these small gods, once self-improving, will be beyond detailed human understanding. He counsels the would-be creators of small gods that they should learn to better understand those who worship "large" gods - gods that create universes like ours, such as mentioned in the bible. To that end, his primary weapon is interpretation of the bible.

This creates a room full of agnostics.

No one who believes we can make a small god should believe we can understand a large god. As long as these people interpret the bible, they represent a belief in their interpretation, and therefore create a non-overlapping-magisteria. Basically, Brin removed the conflict between science and religion for those who will take his advice.

Brin is saying we need to rationalize in order to associate in order to survive. As it turns out, any suitable rationalization makes us nicer, more accepting people. I am proud that David Brin is one of us.

His final point discusses science as appreciation of God. He proposes that when children perform scientific experiments, their wonderment is a finer, more true appreciation of Gods creation than a wrote prayer or words extolling his greatness without really *appreciating* his great works. Scientific revelation is like someone saying to God, "I truly understand you, and I am truly impressed." and then proving it.

On the topic of appreciation, I have often thought that the universe is a self-organizing system that learns to appreciate itself.
But only for a moment. We are that spark of insane emotion burning brightly.
Humans are the love and the insanity in the universe, quickly extinguished.
Love oneself, respect others, a natural state of affairs, the best that can be hoped for, independent of scale, among parts of a whole.
The dream of a cohesive, thinking universe isn't a bad one. Better to be a cooperating part of any vastly superior force. No? Why not think of ourselves as the love in the universe?

What can I say? Humans rationalize compulsively.

Robot Arms Race

Continuing to catch up on Robot Futurism - I re-read Bill Joys article in Wired of over 10 years ago, Why the Future Doesn't Need Us - along with numerous rebuttals, references, and relevant discussions.

The central premise of Joys article is that we are creating dangerous stuff, and maybe we want to think about regulating ourselves. As GNR (Genetics, Nanotechnology, Robotics) tech advances, it gets easier and easier to destroy all human life. We need to considering slowing development of GNR tech, until we can properly defend against it's destructive potential.

Most of the rebuttals to his paper suggest that:

A) It's not that easy to create world-destroying stuff with GNR.
B) If the good guys don't figure out GNR tech, the bad guys will, so we need to go full steam ahead with fundamental research.
C) GNR applications are a moral imperative for quality of life reasons and the advantages outweigh the risks.
D) I don't like Bill Joy because he quoted the unabomber.
E) Anyway, you're right, we need to figure out how to regulate ourselves.

Most GNR sits precisely in the camp of biotech as a threat. Development cost will continue to shrink for weapons that could kill humans and spread quickly with total disrespect for borders.

My conclusion is that labs that study these technologies need to be reasonably careful. The threat isn't huge now, but it will be someday. As with Brains article on Robot Economics (see my last post) the threat is vastly more serious if we are looking a dislocation in the face, rather than a very gradual ramping up of world-changing technologies. No one seems to know which we are looking at. A "Center for Nanotech Control" should probably be funded at a level commensurate with the threat. Depressingly, that's not happening (I hope I'm wrong, I hate being depressed, so please feel free to correct me).

In fact, relatively little has been written on the topic of nanotech defense in the last 5 years. There was a flurry of activity around Joys article, and that was that. It may not have been helpful that most of the predictions that were made publicly by prominent futurists around that time were significantly off. People just seem to have gotten disinterested.

I guess we're just going to have to be happy with the amazing benefits of GNR and not think too hard about the dangers for a while. We'll live forever until we're dead. Wait...

Robot Economics

For my one reader, a quick summary of the last of Marshall Brain's articles in his robot series


Marshall is speculating 30 years out from trends present today.

Robots = Greedy Bastards

He concludes that the centralization of wealth will become extreme as automation (which he calls robots) puts people out of work. So he comes up with a number of taxation schemes to generate a welfare state when this happens, without wanting to call it a welfare state. Well enough. He doesn't take it further than that.

He is probably right about the unemployment issue, because unlike other technologies, robots will create robots. We are making things that are as good or better than we are at most things. We are not making tools anymore that require lots of humans to operate. That's really the fundamental point, most of us will not be needed in this industrial revolution, and why this is worth reading and thinking about.

Orwell is looking smart right about now

It is an interesting read, because it puts you in the mindset of considering 50+ percent unemployment. It is very hard to imagine a way to transition to that level of unemployment from 10 percent unemployment, without generating much more tax revenue. Any other state is a war zone. A fiscally conservative state with few social services would be immediately crushed by internal forces. We do have to consider a very high level of taxation ( aka collective control aka socialism ) in a future that rapidly adopts a high level of automation ( aka robotic workforce), or we have to move to an Orwellian model to repress our citizenry (which is where we are going).

It is, of course, implied that the same or higher level of productivity will be obtained with only half the human workforce, and that our governments are not configured to act in advance of rapidly decreasing employment. We will be in a real pickle. It sounds reasonable as you read it. Over fifty percent unemployment never ends well.

So Brain throws out some plans for socialism (although he picks a narrow definition of socialism to escape this much maligned word). He doesn't take it too far, just covers some possible methods for collecting taxes.

There may also be principles involved when constructing a capitalist-socialist-robot utopia.

For one thing, you want to keep incentives aligned toward innovation. Take only the amount required from the captains of industry to provide a reasonable quality of life for the unemployed. Arguably, you want the unemployed to be innovators, and to be free to innovate and create jobs for themselves and others, but you also want them to be somewhat hungry - their lives not full of stress, but lacking highly desirable comforts. So you would start with the need, and work backwards - the captains of industry need to raise enough money to support the unemployed at a reasonable quality of life, after that point, they can make their lives as ridiculously good as they like with any extra earnings. Taxation methods can then be derived from this principle.

Taking that to the extreme, you have to consider what happens when this morphs into a society in which all work required to maintain the basic necessities human life is done by robots, including maintenance of the robots, generation of energy required, etc. This will raise the bar of social welfare to a fairly high level. It's a long way out, and quite a speculative story, but possible at some point. A lot of fundamental industries will run themselves, and the captains of industry themselves will be outmoded. Every human will be focused on innovation and new industries, as the old ones become, basically, part of nature. O.k. well, maybe I'm an optimist.

Overall, I found Brains robot articles a good way to encourage a geek like myself to think about the future of economics. What would you do for a living if you had your basic needs met for life, but still had the opportunity to make anything of yourself if you worked hard at it? The answer is, ultimately, you would seek your potential (metamotivation as per Maslow). I know I am metamotivated and I find others in the same state to be more fun to hang out with than those who are not. What model makes that world possible? Not the one we have when unemployment hits 50 percent.

And what about those whose metamotivation tends toward evil? The more things change, the more they stay the same. Hopefully our robot overlords won't have time for that shit, and I'm definitely not risking my exoskeleton for their greedy asses.


Marshall also wrote the following two articles on the same topic:

http://marshallbrain.com/robotic-faq.htm
http://roboticnation.blogspot.com/

Putting most things in my wiki - richbodo.pbworks.com

I have a wiki now.

I added notes on my trip to sierra leone there, which was interesting. I'll be adding to it, but the story is all there, including pictures, like these:

A few weeks back a lady from the BBC was interviewing us at Dana Street.

Well, I finally got a chance to listen to the blog post she made. I learned a little about the area myself so thought I would share it. In particular, there is a wonderful interview with some of the Olsons. Here it is. Have a listen. (Update: looks like the podcast download is broken. Reported it. I'll update this if I can find a fixed link.)

It reminded me how lucky I am to have been brought up here.

I may complain that it is impossible to find enough Obscure Sports in Silicon Valley to fill a quarterly blog post, but no one will stop me from making my own. Incidentally, after doing a little research, I have to say that San Francisco's little pinky toe forgets more about obscure sports every day than Silicon Valley ever knew.

Listening to that interview might also make people who grew up here a little sad considering what has been lost in the area.

I'm still finding cool things here, and I took some pictures of one of them. The Palo Alto Electric Car Show is held at Palo Alto High School every year, and for the last three or four years I have remembered to go. It's about 75% homemade vehicles and 25% commercial stuff, and there is always a test track where you can play with the smaller/slower things, like scooters, or...homemade joystick-controlled automagically balancing lawn chairs...



Daily Commuter Solar Trikes:



Model (T?) Conversions:



And a wildly fun electric bike-board product that rides like a combination of motorcycle, skateboard, and surfboard:



Tom has a great opportunity if he can market that thing. It's called the Zummer. I got to ride it and it's a blast and a half. I was grinning like an idiot the entire time. I could potentially even commute with it on the train. I hope all his business needs is some marketing money and a little economy of scale.

That's really the meat of it. Just incredibly neat stuff. Terrific fun. Even practical in some cases. Most of it built by entrepreneurs and enthusiasts on a shoestring. I didn't meet anyone who wasn't discussing their designs, or open to it.

I hope I'm not being too dramatic here. I really felt like I started to understand what Charlie Olson said. We don't have a lot of farms or orchards anymore. We have smog. And we have this.

Other stuff:

The guy who sells the conversion kits for my model of miata was there, too, but the price is still a bit steep (read: I'm still not wealthy). Still, I can dream. I took a few snaps of the commercial products as well...

Tango:



Mini:



Tesla:



I forgot to take a pictures of the Smart. It may not have been one of the factory conversions anyway. However, I did see a Cheap Copy of a Smart From China that the owner had to rebuild for safety reasons that would be embarassing to the guy in the electric lawn chair:



If making stuff was a sport, I could blog the Silicon Valley Making Stuff Sports Daily and I would have to become a cutthroat editor just to shrink it down. I used to go to more than one geeky "meetup" per day when I was in between jobs in the 90s, and we've come a long way from those days.

Script and Screen

At work we use script and screen for co-development and training.

If you want to work with others in a command line environment and don't use these yet, then you should definitely read this post.

Here's how we use it:

The first thing we do when we work together is we all ssh into the box we will work on.

Then we have the person driving start screen, a terminal multiplexor, and then script, a command logging tool.

Then everyone else logs into the drivers multiuser terminal session run by screen by typing screen -x, and can take over driving when needed. We all can read and write to the same set of terminals, and detach or reattach to the session as we come and go.

When we're done, we copy the drivers /home/driver/typescript file to someplace where we keep old training files like /backup/it/training/how_to_debug_that_thing.txt.

NOTE: screen can be used without script to do a similar job, and script can be used without screen to do a similar job. We just happen to use both.

Script:

Just type script to start it. It will start logging to your home directory in a file called typescript.

If you don't want to use screen, and just want to watch what someone else is doing, you can also try the -f option to flush output after each write. This is nice for telecooperation: One person does ‘mkfifo foo; script -f foo’ and another can supervise real-time
what is being done using ‘cat foo’.

Screen:

Setting up and using GNU screen as a collaborative development environment (pay careful attention to the slashes).

Your user is peter, and you want to pair program with user mike.
1) Install GNU screen on the server and learn the ScreenBasics.
2) Drop the following two lines into /home/peter/.screenrc:
multiuser on
addacl mike
3) Execute the following two commands to allow mike to use your screen sessions:
chmod +s /usr/bin/screen
chmod 755 /var/run/screen
4) Peter is already logged into a screen session
5) Mike can type:
screen -x peter/
6) Peter and mike can now look a the same screen windows/terminals and share the same i/o

ScreenBasics - commands you will actually use, in the order you will probably use them

'screen'	start screen session
'Ctrl-a c'	create a new terminal
'Ctrl-a "'	list the terminals in this session
(then hit the number of the terminal you want to switch to and hit enter)
'Ctrl-a Shift-a'	rename a terminal
'Ctrl-a F'	flush the screen when it gets screwed up
'Ctrl-a k'	kill a terminal
'Ctrl-a d'	detach from session
'screen -r'	re-attach to a screen session
'Ctrl-a S'	make two terminal panes in the window
'Ctrl-a Shift \	split the screen vertically
'Ctrl-a Tab'	next pane in this window
'Ctrl-a Q'	go back to one pane, current window

Other Screen Notes:

1) If you don't want to use script, you can get screen to record sessions as well. I think it's 'Ctrl-a H'.

2) The default screen key bindings collide with readline and emacs commands. I should look into remapping them someday.  Hit Ctrl-a-a to go to the beginning of a line.

3) Record and play back real-time textcasts with scriptreplay as follows:

script -t 2>timingfile testscriptfile
scriptreplay timingfile testscriptfile

Note: scriptreplay is a tiny perl script that was left out of most red-hat derived linux-util packages to date. You can get it from a debian derived distro or find it here.

4) If you are using MacOS, you are behind on every open source software application in existence.   You will have to compile and patch screen, script, emacs, and whatever else you use to get a modern functionality set.

5) You can access the scrollback buffer by hitting Ctrl-[.  After that point, the normal vi-like scrolling commands work i-j-k-l, Ctrl-u-b-d-f.  Hit esc to get out of the mode that allows you to scroll.

Links:

** The homepages for script and screen (for GNU/Linux users):

Script is in util-linux: ftp://ftp.kernel.org/pub/linux/utils/util-linux/

Screen: http://www.gnu.org/software/screen/

** Some of the better articles on screen:

http://www.sun.com/bigadmin/features/articles/gnu_screen.html

http://www.kuro5hin.org/story/2004/3/9/16838/14935

http://aperiodic.net/screen/terminal

http://aperiodic.net/screen/multiuser

http://www.linuxjournal.com/article/6340

http://www.softpanorama.org/Utilities/Screen/screenrc_examples.shtml

Patching Screen for MacOS: http://old.evanmeagher.net/2010/12/patching-screen-with-vertical-split-in-os

Silicon Valley Obscure Sports Quarterly Review - Q208

Welcome to the first issue of SVOSQR. In Q2 I thought I would report on "up-and-coming" obscure sports (read: I'm lazy and the sports on meetup.com are not currently at the bleeding-edge of obscurity). Meetup.com links, pics and summaries follow.

Kickball

Friggin Rocktackulous. About 20 people show up. Pleased to find that although I am now older, heavier, and weaker, I can still get that satisfying PWING! sound out of kicking the ball and deforming it into a lively ovoid before the other team catches it. Margaritas afterward in Willow Glen. Surprising amount of blood involved.

Ultimate Frisbee

Super friendly pickup game at Eagle Park in MV. Show up to learn ahead of time. Usually works best if you pick someone approximately your own body shape to cover. Couldn't tell if we were keeping score - could be that I was unaware of the scoring mechanism, but I prefer to think that it's really that casual of a game. They meet in Sunnyvale, too.

Dodgeball

Silicon Valley is in desperate need of Dodgeball leadership!! Things are getting so bad that I have had to find pictures from other sports. The one silicon valley dodgeball meetup was held at Sky High, where they have a dodgeball room made out of trampolines (walls, ceilings, etc). Mixed group with lots of little kids and a few adults. It felt a little unfair to whale on the kids with a red rubber ball, but the realization that I could actually make them rotate on any one axis with a dodgeball strike kept my interest. Apparently, it's next to impossible to get old people to show up to a Dodgeball game. I tried to help and bring in a few folk, but could only drag one brave soul in with me. We were about half the group. Of course, now that the meetup group has gone inactive, there are dozens of interested people pledging to help. Will you be our Dodgeball leader (left picture - the guy who's winning), or will you be woefully unprepared for the next random strike (right picture - that is you).

A warning: There is not enough research to determine what obscure sports do to our bodies, exactly, but we do know that they fully condone the Bush adminstrations definition of torture. Any single obscure sport, picked up for the first time in maybe-ever, will find and cruelly torture muscles that you didn't know you had for weeks. Middle-aged humans are supposed to be dead, and therefore have not evolved to handle more than one attempt at obscure sports per month. Don't do it! But do let me know if you find an obscure sport in silicon valley that you would like me to try.

Thinking Deeply about Concentrated Solar

I always have Polya's How to Solve It on my desk.

There is this one little part of it that I think everyone ignores, at first, in the "Devise a Plan" section:

"If you cannot solve the proposed problem ... Could you imagine ... A more general problem?"

Inside, when we read that, we think, "Are you friggin' kidding me? A bigger, more general problem? HaHa! Ged ouuuda here! I'm a-simplifyn'!" and quickly skip ahead.

I think Divide and Conquer is the first algorithm that comes to our minds. But it makes us think small - we miss data and cannot apply economies of scope.

It's not like we planned to do that.

I think many people initially plan to look at problems through the end of the process, trying to consider all players, evaluating their historical behaviour and setting up a migration path for them, coming to some solution that takes into account as much data as is useful. (Some people might call this "systemic thinking")

But we get myopic too quickly. We get tired. We find an interesting bit and get focused on the minutia, or start arguing whether a given solution to one part of the problem is feasible or not, and we can't give it up.

I was feeling this way about Global Warming. I got bogged down in studying how amazingly unsuccessful activists are at manipulating governments. Turns out, that wasn't one of the more interesting bits.

And now we return you to our previously scheduled feature on Concentrated Solar:

As Jamais Cascio puts it, the Earth will be just fine, it's humanity that is screwed.

Humanity won't make it without quickly shifting to new forms of power. However, I think we now have at least one reasonable roadmap. You can read all about how this technology is can solve our energy problem lots of places.
Who could implement this the most quickly?

Oil companies and our current power monopolies don't want to be replaced. Want to avoid a fight with them? Give them an advantage in concentrated solar. Just get them the hell out of the way and start them working on this problem. No time for a fight, here.

More specifically, the world has enough sunlit land and money to solve this problem 100 times over. The first set of goodies (We include one 100-year land lease and one suitable tech grant per set (but no batteries)) goes to our current oil and power conglomerats. That should be enough to please any stock holder, line any pocket, and guarantee implementation.

The next 99 sets go to entrepreneurs, which should also help.

You win, oil companies. No one has to die over this. Nice big carrot for you. Just get it done.

Of course, if they can't do it, well, first your land lease will get pulled if you can't get a few PetaWatts to market inside 10 years, but more importantly...if you thought all humanities carrot was big...even weilded in our death throes, that stick has got to be devastating. And, frankly, we never liked you anyway.

I'll write my congressman for you! Good luck!

Debunking the Technological Singularity

I have been arguing, at my local coffee shop, that
an empathy test needs to be developed for computer software.

The Empathy Test would be unlike a Turing Test or a Voight-Kampf machine in that the purpose is not to determine whether a thinking machine is human. The purpose is to determine whether a thinking machine is a good match for human society.

Simply fooling a human into thinking that you feel his pain does not make you empathetic. I argue for testing a broad definition of empathy that is more useful to intelligent beings interacting in a civilized society. The pain of others need not be recognized by the subject. The pain must be felt as psychic stress in the subject. The program/subject, therefore, must be cognizant of it's own mortality, and pain must be a real threat to it's well being, as it is to us. Those guys in the asylum aren't exactly in endless loops, but they certainly have a few rogue processes. So the Empathy Test would be, in a sense, a destructive one that arguably mimics it's function in humans.

With luck, these empathy-equipped AIs will confirm the game-theoretic benefits of this feature and propogate it up to their designs. They will understand that this feature is for the preservation of lower races - an endangered species act, if you will. Alternately, it might just piss them off and subject us to summary disintegration. After all, how many programs have you killed today? How many lower species? On a macro scale, are we failing the empathy test?

In any case, I have found today that the point is moot! Recent historical research uncovers striking similarities between our past intellectual follies (SINGULARITARIANS MUST CLICK ON <-THAT LINK) and our current failed delusions of technological grandeur.

Clearly, I was entranced by the mental crack that is the singularity novel. For those of you with the same addiction, you can shoot up with this open content novel. Confirmed grade A stuff. But please, don't share dirty algorithms.

Rock genre terminology considered asinine

Recent craigslist internet engineering jobs, exclamation point:

** Rock Star (Affordable) Flash Developer Needed ASAP!

** Seeking a rock star DBA for our production environment!

** Great Opportunity for a Rock Star Intern!

Before interviewing for these positions, be sure to comb your mullet and put a cucumber down the front of your spandex pantsuit.

On any given day, about 30 craigslist job postings in my area are looking for "Rock Stars". They are all really looking for "programmers", so, as I am about to enter the job market, I happen across them with increasing frequency.

I have to ask myself: How the heck did "Rock Star" eclipse "productive"?...and why haven't other industries caught on? Where did this trend come from?

No, Captain Klaa(pictured) has not been going around writing corporate dress codes, and yes, perhaps these HR departments are a bit too exuberant(see below). But that's not why I'm looking into this.

I don't have a problem with the use of the term "Rock Star" per se. I don't want to make fun of anyone. I enjoyed Spinal Tap as much as the next guy.

No, I'm looking into this because the trend really got on my nerves. I couldn't put my finger on why that was; so I explored it, and learned something.

I think these employers are trying to do two things:

1) Find programmers that are very productive (top 1% preferrably).
2) Imply that they will treat them well.

What I think they really want is to:

1) Attract programmers who know they are very productive and easy to work with.
2) Imply that they their team is productive and easy to work with.

If you have recently read Joel Spolsky, you may feel the need to replace "productive" with "gets things done" - I won't feel bad.

Thinking about how these employers can get what they want, I found what I really want: a productive, easy-going team. The heart of my problem with a team of Rock Star's is that it's so far from that ideal.

I asked roughly the same questions that employers ask. It was so informative to me that I would recommend it to anyone looking for a job. Here's what I came up with:

1) How do I know I am productive?:

Well, I can measure it.

The employers who are looking for rock stars have probably read that timely tome - The Mythical Man Month, in which the productivity of programmers is said to vary by an order of magnitude by skill alone. Well, this is one of the things that is still true in that book, but not in the way most people probably think.

Most people know how to measure their own productivity. They can describe what they have produced, and discuss it at length. "I developed X in Y weeks and I here it is", etc.

To most employers, your past productivity in the domain of the job in question is the primary measure of your likely future productivity.

Most people are o.k. with that. It's just common sense that you improve at a task with experience. This is hard to measure, but anyone who plays chess might assume that from competent to expert there may be 100 or 1000X improvement in most fields to be gained by experience. As it turns out, this is a highly contentious assertion. No one knows how much experience really has to do with it.

In absence of a candidate that is productive in the required domain and easy to work with, an argument can be made that a candidate that is trainable and easy to work with will do.

Trainable is usually a secondary requirement, and you can measure it the same way you measure productivity, based on past performance. In the case of a programmer out of school, trainable may be the only applicable requirement.

The more experience and intelligence the better. That's nice, but...

2) How do I become more productive?

Most people have a decent understanding of the factors upon which their productivity depends. It may vary from person to person and purpose to purpose. For me, right now, it consists of four things that I seek to improve upon daily.

Domain experience:

Produce more. Focus on one job for a while, and you will become an expert. I may be an order of magnitude more productive at writing support scripts or IVR applications than I am at writing web applications. At some point in the near future, however, I expect this situation to reverse. This just makes sense. I am working on web apps every day. If I want to get good understanding the core concepts of a framework and writing large programs in that framework, then there is no substitute for doing that.

Tool expertise:

Programming tools are made from software and improve productivity. New and better tools come out every day. If I spend time every day learning tools, I will improve my productivity. Commit to this, and you will improve.

Mental and physical health:

Stay healthy. My levels of pain, discipline, and energy vary based on my lifestyle. I get up every morning and excercise, clean up, hug my wife, drink coffee, and solve a puzzle. If I don't get a healthy start to the day, or if I don't take care of myself in other ways, I am sure my productivity will suffer.

Environment:

As a programmer, I work best either in a quiet office or pairing with one or more team members at about the same skill level. I can rank environments for productivity as well. The library is fine, a coffee shop is not so good, and home is right out - too many non-work distractions. Nothing compares to a serious, conflict-free, office work environment.

All I can do here is be aware of the quality of my environment, which varies from job to job. Experimenting with environmental improvements can help, as do these helpful techniques for tough environmental situations.

Kaizen.

3) How do we know when someone is easy to work with?

Probably the most important and tricky part of the hiring process, for both the employer and the candidate, is measuring soft skills.

If a candidates tech skills are not up to par, you have to train them. Fine.

Employees with very poor soft skills can destroy an entire company. Experienced employers and employees know this. So what we are looking out for here, are the bottom few percent of the employee pool in soft skills. No one wants a report or a manager like that.

My soft skills can be measured, and so can those of any company. We just ask each other how we handle situations that matter, and check references.

For my part, I have to ask myself tough questions: How many co-workers have I helped, how many have I hindered, what tough problems have I solved with them, what have I learned, and how can I improve?

So how can I improve? Aside from discussing this with past co-workers, knowledge will help: PeopleWare.

It can't hurt to improve, but I think most people are probably o.k. on soft skills. Still, the better adjusted the team, the better for everyone.

And now, a word to folks advertising for Rock Stars:

I don't expect hiring managers to read this, but...

If you would like to project an image of your programming team, a gathering of Rock Stars is probably not what you want. Rock Stars are people who produce hit songs and are worshipped only as long as they keep pumping them out. A collection of rock stars are not likely to work together long.

Sounds like solo-superman programming while surrounded by dysfunctional sycophants and confrontational peers. Probably not what you meant. If that is really what you meant, then I suggest a different perspective.

I could suggest a different analogy...A construction crew is a closer match than a Rock band. It could be that your construction crew wants to design and build the next Guggenheim and drink beers after work, but it's a construction crew all the same.

Better yet, drop the analogies. Mention your team, your management style, your process and your product. Mention that you would like applicants to discuss what they have actually produced, providing examples where possible. Maybe lead with something like: "Highly productive team seeks C programmer" - or whatever actually describes your team and what you are looking for.

Mention that soft skills are important up front. This is a very good sign.

And...Rock on.

Swig-C-Ruby-Pointers Hello World

I'm trying to write C libraries to do some things on the Mac that are not easy to do with Ruby. I found that I had to read several documents and experiment around a bit with SWIG to call a C library function that took a pointer as an argument. This is just one of those things that should not take that much time to figure out.

C library functions that take pointers as arguments and return ints (that covers most of the c library functions I have written) ultimately return an array to Ruby. Uncovering that little factoid, and the swig interface format required to make that process work, was the tough bit.

So, I'm taking a few more minutes to make sure you don't have to do that (and to make sure I don't have to do that long after I forget about this exercise).

Step Zero: get swig.

I install all open source software on the mac with fink. Fink Swig

Step One: Copy my example code - inline below.

I provide what you need to make a ruby callable module called Example that contains the C function SimpleFunc() that you will call with a little ruby test program called testsum.rb.

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 48
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

Three of these files you already understand:

sum.c - your library

int SimpleFunc(float *modify_me)
{
*modify_me = 5;
return 1;
}

sum.h - your library header - not used by swig unless you tell it to - don't need it here.

testsum.rb - ruby program that calls your library

require 'example'
afloat = 2
# The first return value gets set as expected in first_returnval.
# However, SWIG puts the float in a second return value.
first_returnval,second_returnval = Example.SimpleFunc(afloat)
puts "Your float is #{first_returnval}, and the return value is: #{second_returnval}"

The other three files are specific to getting your swig library going:

• example.i - a definition of your library for swig in swigs definition language. INOUT is a SWIG typemap, so typemaps.i is required.
  

%module example
%include "typemaps.i"
%apply float *INOUT { float *modify_me };
int SimpleFunc(float *modify_me);

• extconf.rb - a ruby program that creates a makefile for your library

require 'mkmf'
create_makefile('example')

• get_it_done.sh - the commands that you run to generate a ruby module from your c library using swig

#!/bin/bash
rm *.o
rm *.bundle
rm wrap_example.c
rm Makefile
swig -ruby example.i
ruby extconf.rb
make
sudo make install
ruby testsum.rb

Step 2: Run the get_it_done.sh script to build and test your module. (it will ask for your password to install the library)

user-64-9-234-209:~/src/c/idlerlib richbodo$ ./get_it_done.sh
rm: wrap_example.c: No such file or directory
creating Makefile
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c example_wrap.c
gcc -fno-common -g -O2 -fno-common -pipe -fno-common -I. -I/sw/lib/ruby/1.8/i686-darwin -I/sw/lib/ruby/1.8/i686-darwin -I. -I/sw/include -c sum.c
cc -dynamic -bundle -L"/sw/lib" -o example.bundle example_wrap.o sum.o -lruby -ldl -lobjc
install -c -p -m 0755 example.bundle /sw/lib/ruby/site_ruby/1.8/i686-darwin
Your float is 5.0, and the return value is: 1

Step 3: Look at the five new files you just created, and understand what they do:

user-64-9-234-209:~/src/c/simplelib richbodo$ ls -l
total 152
-rw-r--r-- 1 richbodo richbodo 3009 Oct 12 16:42 Makefile
-rwxr-xr-x 1 richbodo richbodo 16316 Oct 12 16:42 example.bundle
-rw-r--r-- 1 richbodo richbodo 61 Oct 12 16:24 example.i
-rw-r--r-- 1 richbodo richbodo 17695 Oct 12 16:42 example_wrap.c
-rw-r--r-- 1 richbodo richbodo 5744 Oct 12 16:42 example_wrap.o
-rw-r--r-- 1 richbodo richbodo 42 Oct 12 15:52 extconf.rb
-rwxr-xr-x 1 richbodo richbodo 90 Oct 12 16:41 get_it_done.sh
-rw-r--r-- 1 richbodo richbodo 46 Oct 12 16:36 sum.c
-rw-r--r-- 1 richbodo richbodo 24 Oct 12 15:46 sum.h
-rw-r--r-- 1 richbodo richbodo 644 Oct 12 16:42 sum.o
-rw-r--r-- 1 richbodo richbodo 67 Oct 12 15:57 testsum.rb

• example_wrap.c - created by the swig command, this a c wrapper for your library with a bunch of additional wrapper functions that translate your functions and data into ruby callable functions and data. see chap 21 in the pickaxe.
• Makefile - this is the makefile that was generated by extconf.rb. It will compile your library and that wrapper and make the mac bundle for you.
• sum.o - the object file generated from sum.c
• example_wrap.o - the compiled version of example_wrap.c
• example.bundle - mac osx stores code in bundles, so make makes one and puts it in your site-ruby directory when you type "make install"
  

So that' it. You make that swig interface file, you call swig. Example_wrap.c gets created. You make the extconf.rb file and run it. A makefile gets created for you. You make your project by calling make and you are done.

References:

• Chapter 21 in the pickaxe book.
• The ruby swig page: http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn5
• The swig basics page: http://www.swig.org/Doc1.3/SWIG.html#SWIG_nn3
• Apple Developer Docs: http://developer.apple.com/documentation/
  

Method for organizing volunteer efforts

The Cancer Beatdown

At it's simplest, it's just a task manager for researchers who would like to utilize volunteers in the search for a cure. For volunteers, it's a way to get their hands bloody at cancers expense. "No, you won't cure cancer, but maybe once in a while, you can come on over here and get a few good licks in". And, yes, I'm going to continue to refer to fighting cancer in more colorful ways than just "fighting cancer". It's quite satisfying.

No money, no donations of protons or neutrons. Just electrons, photons, and elbow grease. This isn't a site for beggin; it's just a site that invites others to get in on the beatdown while the beatin' is good.

The idea is based on the premise that the pool of smart, motivated volunteers is underused and underorganized by the cancer research community. In other words:

1) there are a lot of very smart people who would get a profound satisfaction from knowing that they contributed in some small way to developing a cure for cancer.

2) there are a lot of researchers who will buy that exposing some of their tasks in a sensical way to an army of smart people who want to work on them could speed their work.

One case in which this might work is:

A researcher needed to develop a significant new body of software, and was looking to task some portions of that development out to volunteers in a test-driven manner - "I write the tests, you guys make as many as you can pass before I do".

I recently participated in agile development of this sort, using pivotals excellent agile project manager, which is influencing my thinking on this type of application.

The basic site workflow for Cancer Beatdown is as expected:

1) Site manager invites a few researchers who are doing promising work.

2) Researchers post the task, whether it's stuffing envelopes on-site or coming up with a new way to search a massive database for correlations. The required form of the solution is also specified.

3) Volunteers propose solutions.

Some sensical reputation/core user policies would be adopted - i.e. Researchers or the site manager can invite more researchers, after vouching for them. Volunteers are invested in performance.

Personally, I would love to volunteer for some well-defined and promising projects in which I could invest one day per month. I know some people who would never consider such a thing, and some that would invest considerably more time. What do you think?

Selling on Ebay

Just found this old draft of ebay instructions. If you are going to start selling stuff on ebay, copy these conditions of auction and live by them, it will save you a lot of time and money. The one adjustment you will have to make regards buyer feedback. I stopped selling on ebay when they stopped allowing negative buyer feedback. You can just pull or rewrite those three lines:

Conditions of Auction:

You must agree with our Conditions of Auction prior to bidding. Please do not bid if you do not agree to these conditions.

Shipping Policy:

You will pay shipping as described in the auction.

To avoid damaged goods and provide timely shipment, we will ship as follows:

We only ship air, on-line trackable, on-line signature-required, and fully insured. Internationally, we only ship USPS Express Mail Service.

We do not ship ground by any carrier.

To ship, we require your name, confirmed address, and valid phone number.

We reserve the right to cancel the transaction if we cannot reach you by phone.

Payment Policy:

To avoid fraud, we will ship as follows:

We require payment prior to shipping. We ship within seven days of receipt of payment, usually much faster.

We do not accept payments by check, moneygram, western union, or partial payments of any kind.

Return Policy:

You can return the product within 30 days of receipt if not satisfied for any reason subject to the terms and conditions below.

*** You agree to:

Fully insure any returned item, to the full value of the auction, and to ship via an on-line, trackable, air service.

Provide on-line tracking information on date of shipment.

You will be fully refunded within two days of receipt of goods that are in the same condition they were in when shipped to you.

You agree that we may deduct any costs associated with damaged or missing goods returned from your refund.

Right to refuse sale:

To avoid scams, we reserve the right to refuse sale to buyers with:

* No Feedback
* Poor Feedback
* Private Feedback
* Unconfirmed Shipping Addresses or incomplete contact details.

Service Policy:

No service is provided. No service guarantees are provided.

We will, on a best-effort basis, answer questions via email anytime, or via phone by appointment.

We don't mind answering any questions at all, and we typically get back to you same-day.

Again, those are the conditions of sale. You must agree with those conditions prior to bidding. If you take exception with any of those, please do not bid, or contact us before you bid so that we can work it out. Thank you!

Telepathy UIs

Here is a rundown of "brainwave" game controllers. (bonus idea included)

I first heard about an implementation of one of these in the early 90s by a company called "the other 90%" run by former Atari founder Ron Gordon. AFAICT, very few were sold. Anyway, I still believe it worked. So I had a discussion with someone about this last night. He didn't believe it. Here is some history on the topic:

1974 - EEG control (Sobell - VA Neuropsychology Lab) - Still looking for the actual research study.

1996 - CNN reporting on The other 90% (Atari's Ron Gordon) MindDrive application:

2004 - BBC reporting on MIT implementation

2006 - MSNBC interviews Don Clark of Wall Street Journal reporting on Emotiv game controller.

The reason this works is twofold. First, the composite electrical activity of your brain can be measured and decomposed by frequency and a half dozen clean signals can be discerned. I would call these brainwaves but, according to wikipedia, that is frowned upon for some reason. Second, these patterns change according to thought activity, which is under our control.

Anyway, if one reads about non-invasive brain computer interfaces, it becomes apparent that there is plenty of research in the area. There are also several successful and useful implementations. Not all of them EEG based.

Bonus Idea:

Wouldn't it be cool if:

My jabra bluetooth headset could also send composite brainwave activity to my wildly powerful cell phone, or maybe even my uber-powerful computing cluster at Name_Your_Favorite_Company? In that case, I could generate messages by thinking, while the headset reported the current character.

I have heard somewhere that these game controllers allow you to manipulate 6 tokens based on training them to understand when you think in certain ways.

The first idea that comes to mind is the concept of scrolling through groups of tokens. Lets try sending telepathic messages to each other with just the thoughts Up/Down. (After taking a look at some EEG decompositions, two tokens is, for some reason, quite believable to me.)

Me: Think Up
Headset Audio: "A through E"
Me: Think Up
Headset Audio: "F through L"
Me: Think Down
Headset Audio: "F through L it is - F"
Me: Think Up
Headset Audio: "G"
Me: Think Up
Headset Audio: "H"
Me: Think Down
Headset Audio: "H is the first letter."
...

You get the idea. So you form some text, which gets sent to whoever you are configured to send this stuff to. This gets converted to speech and played back in their headset. They, in turn, send you text with their bluetooth audio/telepathy headset.

Not at all the best UI, but if you can really train yourself to manipulate six binary tokens, the sky is the limit. Can't you just see schoolteachers spectrum-jamming bluetooth signals?

I would appreciate a study that shows a Non-Invasive BCI that was reliably trained to a larger number of tokens. Until then I'll limit my imaginings to two.

Even with two, it is easy to see that the combination of mic/earpiece/brainwaves is powerful. Imagine setting the context with voice: i.e. saying "computer doors" or "computer radio volume", then just thinking up or down to lock or unlock the doors, or control radio volume.

I hope that no one patents this crap and charges exhorbitant amounts of money for this type of tech.

Update: I have to add this link to a cool open-source EEG hardware project: http://pceeg.wikia.com/wiki/Main_Page

You would be surprised what you can find in Open Hardware these days. I will post specs of all the components of the device I describe if I have time. There should be prior are for every component.

Getting Things Done - David Allen - Reviewed by a busy person

I have recently been reading a number of personal productivity and project management books (in typical ADD parallel fashion). If you are a very busy person, you might scroll to the commentary at the bottom of this article, as I am a busy person as well, and I have a few points to make to you.

Summary: Getting Things Done. David Allen. Good productivity tricks. Buy it.

Definitions:

GTD - Getting Things Done - Method for identifying and managing actionable stuff.

Stuff - anything you have allowed into your psychological or physical world that doesn't belong where it is, but for which you haven't determined the desired outcome and the next action step. Stuff clouds your mind until you identify and track it.

Workflow - everything in the book revolves around this list.

1) collect things that command our attention
2) process what they mean and what to do about them
3) organize the results, which we
4) review as options for what we choose to
5) do

Incompletes - categorized stuff not done

Collecting - You are always collecting (work flow 1) stuff by identifying and tracking it.

Collection devices - capture stuff - notepad, pda, email inbox, physical inbox., etc.

Processing triage (workflow 2, 3, and 4) -

1) If it's not actionable, trash it.
2) If it's actionable and will take less than two minutes, do it.
3) If it's actionable and will take more than two minutes, delegate or defer to calendar or "next actions"

Projects - special case incompletes - they are a list of actions that needs to be made and triaged separately.

Next Actions / Next Action - prioritized list of things that need to be done and cannot be put on the calendar because they don't have an associated time that is not "ASAP", next action is at the top. You MAY divide your Next Actions list by category - phone calls, support requests, etc.

Waiting Actions - actions that are blocked on other people.

Lists required for David Allens Method -

* Projects
* Next Actions
* Calendar
* Waiting For

Daily Review - Calendar and Processing Triage

Weekly Review - Everything : gather, process, update all lists.

Decision making criteria:

1) context - where, how can this be done
2) time available - when is there time for this
3) energy available - how much of your available energy would this take
4) priority - which action that can be done has the highest payoff

Purging and getting started:

1) Block out a day or two
2) Buy the office gear he recommends
3) Collect every piece of stuff of every kind and put it in a single inbox
4) Process stuff as usual

Also in this book:

Project planning - not particularly interesting if you are comfortable with your project management skills.

Decision making - very reasonable but not inspiring or particularly specialized section.

Part 2 is implementation ideas for this system - probably a must-read if you decide you want to integrate part of this system into yours - these are all productivity "tricks", similar to those you would find in any personal productivity book, although there are a few unique ones. I will definitely come back to this section in my "organization time".

Part 3 is an analysis of the value of the system. I skipped it at first, but came back to it this morning, and he's got some good points. Worth reading.

Links:

This book is a huge geek-cult hit, so google might be your best bet, but here is what I found useful:

Wikipedia summary of GTD

GTD Tiddly Wiki - a very cool javascript-only wiki that supposedly lends itself to these lists. - in any case, any wiki will do as a list manager, but TiddlyWiki is a single javascript / html file with everything in it, so it's great for offline use. Sync is always a problem, even with this method. You won't always use the same PC. Once solution is to put your tiddly wiki on a thumb drive, in the hopes that you will always be able to plug it in. I tried it and liked it, but will abandon it due to sync/speed concerns and merge back into an svn managed wiki.

Location of a blank GTD TiddlyWiki

Implementation Details:

I did make several purchases based on David Allens advice. I also got buy-in to spend a couple days doing a purge from a few other folk before starting - an excellent recommendation as it turns out.

During my purge I found that the layout of my desk and filing system needed to be optimized right up front for this activity specifically. One thing that doesn't get emphasised in the book is setting up your filing system completely before starting your purge. It's important. You should do that, and set your inbox and trash can right next to the filing system, then begin by bringing your paperwork in. You will need a lot of space. You will probably have to purge your entire filing system if you are really following the book closely.

Oh, and if you are a normal person, you will have to do your purge over the course of many days. The better part of two days got me most of the way there, but I had a lot of work to do over the next couple weeks. Expect 10-20 hours work at least, not including purchasing gear he suggests, if you choose to do that.

Commentary:

Continuous Work Flow Management:

There are some adjustments that I would make to his program for very busy people. Weekly or daily triage is not an option for busy people. For busy people, it is constant, just like the collecting phase, and it has to be treated as a constant if you want to stay on top of it.

As a support manager, when I get in in the morning I might have dozens of new tickets (hundreds already triaged), plus ringing phones, a full calendar, and it just keeps coming. It's like managing a busy restaurant kitchen. I only have the luxuries assumed in this book late at night, on weekends and holidays.

After 12 busy hours at work, the last thing you want are huge lists to triage. So you have to work it constantly - collecting, consolidating and triaging. Yes, you still have to make concerted efforts to triage as completely as possible during the slow times, but infrequent triage won't keep you sane. The drive to organize is more powerful and more urgent for busy people.

There are limits to continuous work flow management. It is easier to rework constantly if you have a reasonable percentage of simple tasks, because you can multitask simple jobs. (i.e. phone call plus monitor a few things plus work down a list of support tickets is do-able, while coding plus work down a list of tickets is nigh impossible). Continuous management is sub-optimal in terms of peace of mind. At some point you have to accept that you are resource starved, and can't fix the problem by shoving management into the gaps.

The Drive to Organize:

There is one profound insight here. The drive to obtain the peace of mind that only a complete and properly prioritized task list can provide is irresistible. He covers this right up front and it's so damn true. Without this peace of mind, life sucks and productivity suffers.

I would add that denial of responsibility is an insidious temptation.

There is a relationship between The Drive To Organize and Neuroticism. I could write an entire paper on Neurotic Time Management. Man, I have been there. If you can do something, it's a good thing to do, and you know you are competent and maybe even the best person to do it...AND you are Neurotic, then you will accept responsibility for it. If you are Neurotic enough, your task list is effectively infinite.

The discipline to "just say no" is covered in a section called "How do you prevent broken agreements with yourself", which for my money is the best section in the book. There is probably nothing there you don't intuitively know, but surely some things you need reminders of: Either don't accept the task, renegotiate the agreement to do it, or do it. Not rocket science, but words to live by.

The Problem with Meetings:

"I envision a world in which no meeting or discussion will end, and no interaction cease, without a clear determination of whether or not some action is needed- and if it is, what it will be, or at least who has responsibility for it." - David Allen (Part 3 of Getting Things Done)

How many business meetings end without the coordinator requesting: "List your action items." I hope that I never run another meeting without making that statement, and never leave a meeting where that request is not made without asking why.

Glad I came back to section 3.

What other busy people think:

I bought two copies of this book which I have loaned to two other busy, organized people. They both said the same thing - yeah, he's got some good tricks. Neither could adopt his system to do their day to day work any more than a kitchen manager at a busy restaurant could, but they both got a good trick or two out of it.

Alternatives to Antiproperty Incubation

Really common question:

"Does the patent system do more harm than good?"

Just about everything I read assumes that the answer is: "No - most patent systems are a net good for societies, but we can do better."

After all, patents are just antiproperty with a 20 year incubation period as a government-granted intellectual property franchise. In other words, patent systems carry a lot of baggage.

Assuming that the common wisdom is true - the next question is:

"What's better?" Or more specifically: "Are there systems that can be developed alongside the patent system that can provide us with additional IF?"

I was recently alerted to a paper by Tom Bell discussing one such potential parallel system - scientific predictive exchanges. (spex) I like the idea, and I can see how predictive markets could not only encourage research, but, were the claims to be "bet" upon collaboratively developed, they would potentially expand IF.

SPEX aren't all that different from your company's internal office pool on "what product Google will announce next?" or "when will the release date of your own next product will finally arrive?". These predictive games may not change the world, but good ideas and good data can come out of them (and you might make a few bucks, too!).

A little extra investment in the implementation of a SPEX, however, might make all the difference in its utility. As I alluded to previously, if someone can come up with a good predictive scientific exchange that encouraged collaborative development of scientific claims, then well defined, high-quality ideas might develop that did not previously exist. Exactly what the patent system is supposed to do, without the abuses and high transaction costs.

To restate the last question in light of this new system, assuming SPEX ideas are cheaper to society than patented ideas (and we have no reason to believe otherwise):

"Can a SPEX be designed to encourage the generation of useful ideas, especially those that would qualify as prior art?"

A SPEX that answers that question in the affirmative might not be designed so much as a "market" as a collaborative tool. This train of thought brings me a conclusion I come to often: Keep working on on-line collaborative tools. They hold rare potential as technological solutions to social-political problems.

Anyone up for a predictive market plug-in to MeidaWiki?

UPDATE: HFS, Batman! An idea incubator website thingy! This is almost totally unrelated to anything else I've discussed here, but so cool that I can't help myself from linking to it.

Actually, Cambrian house is just a web apps company that encourages anyone to post ideas for them to develop, and anyone to help develop them. If they are successful, well...I would like to say that they will encourage the documentation of a lot of useful, high quality antiproperty. The initial stage ideas are very thinly described, however, and Cambrian house is not capable of implementing more than a few of them. The thing is, given two generally useful ideas, the very well documented idea will be very useful. Most patent systems do a reasonable job of encouraging good documentation.

On the other hand, Cambrian house does publish specs as they work, so that others can contribute labor for royalty points. Cambrian house is just starting out, and they are highly involved in the voting process, so maybe they can encourage something closer to patent quality work.

I love this idea.