Subject: Re: Kent Beck's talk
From: Brian Behlendorf <brian@collab.net>
Date: Thu, 19 Aug 2004 23:14:22 -0700 (PDT)

On Wed, 4 Aug 2004, David Ascher wrote:
> Tying in with another interesting talk at OSCON, the future is probably 
> fine for Kent assuming (as I do) that he is one of those Great Hackers 
> that Paul Graham talked about in the opening keynotes 
> (http://www.paulgraham.com/gh.html) -- it'll just take a while before 
> Great Hackers can get the compensation that they deserve (assuming that 
> they really are orders of magnitude more useful to the companies that 
> hire them than good hackers).  The future is _not_ fine for 
> not-very-good hackers who aren't willing to make compromises w.r.t. 
> their self-actualization needs.

We've talked about hacker-as-artist, and hacker-as-entreprenuer, but 
there's a way of thinking about engineers that I see most outside of open 
source circles that would be better described as hacker-as-surgeon.

We float in circles where software failure is not just tolerated, it's 
nearly encouraged with "release often" and other memes that turn bugs into 
invites for participation.  I love being there - being unafraid to fail 
means being much more willing to take daring risks that can create giant 
leaps.

But most of the paid programmers in the world aren't allowed such slack. 
Most write code in environments where the ability to reliably produce code 
with low amounts of failure and on a predictable schedule is more highly 
valued than bursts of brilliance.  Instead of the Edison-style tinkerer in 
the lab laboring to produce the Next Big Thing, most developers are 
expected to act like surgeons who are able to look at an X-Ray or 
directions from another doctor and decide, with consistancy, how to fix, 
how to improve, how to implement a solution.  We don't pay surgeons for 
their creativity, aside from how they apply creativity to the requirements 
of correctness and predictability.

This is why we won't see hacker-as-artist become a predominant model - I 
even question whether it ever was.  There are great products that came 
from brilliant engineering teams where artistry is allowed to reign - 
Apple seems quite adept at this.  But those bursts of brilliance no doubt 
only came to light thanks to a much larger effort of these careful, 
predictive sort who could turn a promising prototype into reliable 
software.

Any good engineering company will dedicate some amount of resources to a 
speculative, slack-filled, its-OK-if-you-fail R&D department, where 
there's no commitment to specific features on a specific schedule.  Other 
good software companies make names for themselves in bringing 
predictability to chaos in the same way insurance companies or mutual fund 
managers do, and that's how you can build a business at all on software 
built by open source developers.

The only thing, possibly, to feel that may be tragically lost is the 
potential for someone to build a better mousetrap, sell that mousetrap for 
$700 per copy to 1 million people (or whatever), and have that famous 
rags-to-riches story (or create new companies along the way, or use that 
pile to start a non-profit, or whatever).  As software moves to more of a 
services industry, it's a lot harder to have those big bangs.  But it's 
been a long time since that anyways - Shawn Fanning didn't exactly make a 
pile from Napster (factoring in the various lawsuits involved), and that's 
the last example I can think of where a software product grew from humble 
beginnings to ubiquity.

I do think, though, that software-as-a-service is much more economically 
equitable - there's more chances for most people to make a living, even a 
living-plus-plus, even if there are fewer big-bangs.  But will that 
demotivate people from entering the industry?  The types who'd 
rather take the gamble of great rewards over the more certain modest 
rewards?  History will tell, I guess.

 	Brian