Free for all

What would happen if tomorrow we made freely available all the source code to Code Collaborator?

Can you imagine Intuit releasing the source code to Quickbooks? Or EA Sports handing out the code to NHL 2008? Even cool companies like 37signals go so far as to encrypt their hard drives against theft of code.

Most software companies would consider such a thing contrary to everything they hold dear. But sometimes it's worth challenging assumptions.

Why not?
So what are the specific reasons to not publish our source code? What are we afraid of?

Well this should be easy...

Competitors catch up to us quickly because they can easily copy everything we've figured out how to do: Cool AJAX/DHTML techniques that they don't have; Super-smart file-differencing algorithm; Interfacing with 7 version control systems while handling all the corner cases.

We show them the way, they catch up, and suddenly we're neck-and-neck instead of keeping our lead in awesome features.

Support becomes impossible as customers make arbitrary changes to the code. They could change anything -- from benign things like CSS styles to introducing a subtle bug in application logic. It's hard enough to track down problems in the field without "all the code" being a variable!

Besides supporting bugs, you know we're going to get source-level support questions. Yeah you can say "we don't do that," but it's going to happen and it's hard to turn people away.

Potential customers scared away after seeing the state of your code. You laugh, but it's a valid concern. Much of our code is well-documented and well-tested. But some isn't. Some is downright embarrassing. You never know what someone else's impression might be.

Yeah, but not so much. Apparently all these fears are unfounded.

Here's my disconnect: There are small companies just like us who publish all the source code to their software, and none of these concerns are a problem for them.

Take for example the issue-trackers JIRA (Atlassian) and Fogbugz (Fogcreek). Both are in an insanely crowded space with fierce competition ranging from open-source to small-company closed source to big-company software/services.

And yet, both are popular even with the fear of competitors stealing secret sauce. Both are highly profitable, not buried under a mountain of technical support. Both have ugly pockets of code, but I've never even once heard anyone mention that as a downside, not online, not in the field, and certainly not as a reason to choose a different product.

So what's the explanation?

Ummm, just because?
All the following are theories. I honestly don't know the answer.

To me the biggest upset is in the assumption that competition automatically gets tougher. Here's some possible reasons why it doesn't:

1. Writing an algorithm is just the start. So let's say a new competitor steals our awesome, optimized, unique AJAX/DHTML code for real-time, context-sensitive chat. So now we're even? Well it doesn't matter until a potential customer is checking them out, which means executing on marketing and advertisement. And it doesn't matter if during the trial we give the customer a personal demo and responsive tech support while the competitor asks him to post a question on a forum. And it doesn't matter if all they can claim is that they're "the same." All else being equal, most people will go for the incumbent, proven, most popular tool, which is us.

2. Competitors need to differentiate. Even if you could be just like another product, you don't want to be. Sure you might pick up some ideas for algorithms here and there, but that's not enough by itself to sway potential customers.

3. Developers like doing things their own way. Every good developer I know wants to write code herself. Yeah you might pick up some ideas but your first reaction to almost any code is that you could write it better, organize it better, document it better, make it more flexible, whatever.

4. Most code is not reusable. Almost all our code depends on assumptions, design, and other code that is relatively unique to our product. Sure we have some utility classes that could be copied and reused, but those are the kinds of things that are easy to unit-test-to-hell which means it's not hard to reproduce it even without our source code.

5. Serious companies don't steal. Any serious competitor will have internal rules about stealing code, even if it's an open-source project. Once again, little tricks here and there could sneak in, but not wholesale copies of libraries. A serious competitor has too much to lose -- revenue, customers, possible future upside -- and if that comes out it's all over.

The other two items are easier to understand. Support can be kept in check:

1. Most people won't change the code.

2. Limit support on source code changes. Your customers will understand that you cannot provide unlimited support on that front, so you can just pick and choose how much time to spend helping someone. It's no worse than a competitor who is closed-source.

3. Include a "source changes" report in tech support reports. We have things like verbose logs, config files, and diagnostic pages, so just add something that tells tech support what, if anything, has been changed by the customer. If something has been changed and you cannot reproduce the issue, you can now reasonably deny tech support unless they can reproduce with a clean installation.

So... are you going to do it?

Nope. :-)

Twenty words for hoax

Some things you just take for granted. I'm as skeptical as the next guy, maybe more so, but even I can't spend my life trying to disprove everything I see.

So I was both surprised and bummed when I found out that Eskimos don't actually have 20 words for snow.

In fact, the Inuit language has a few root words for things like snow, slush, and blizzard. In fact they have about the same number of these words as in English. Then, because Inuit is polysynthetic, you can tack on almost anything else to that root word.

The example from the article above is:

You would take the "snowflake" root qani- (or the "fish" root or whatever); add a visual similarity postbase to get a stem meaning "looking like ____"; add a quantity postbase to get a stem meaning "stuff looking like ____"; add an augmentative postbase to get a stem meaning "lots of stuff looking like ____"; add another postbase to get a stem meaning "gathering lots of stuff looking like ____"; add yet another postbase to get a stem meaning "peripatetically gathering up lots of stuff looking like ____"; and then inflect the whole thing as a verb in the 3rd-person plural subject 3rd-person singular object past tense form; and you're done. Astounding. One word to express a whole sentence.

But that doesn't count because the intent of the saying is that, when it comes to snow, Eskimos can detect subtle gradation and nuance, and they had to describe this in words to adapt to their harsh environment. It's used as the quintessential example of language relativism, wherein the need for cognition of special concepts results in new words, and conversely that growing up with a certain language affects the kinds of things you can think about and express.

But it's not true at all for Eskimos. They have about the same number of words for snow as we have. They just chose to add modifiers without adding spaces and some anthropologist (OK, an important anthropologist, but that makes it worse) decided to make a claim that most people don't know enough to argue.

But don't despair, I have a fix! (You shouldn't complain about something unless you have a proposal for a fix, right?)

The Jews have 20 words for "penis." I can think of 8 just off the top of my head: putz, schmuck, schmendrick, schmeckel, schlong, schmohock, petseleh, and schvantz. There's probably more.

Tell me a story

Malcolm Gladwell is as successful as any non-fiction writer could hope to be. The Tipping Point was the surprise #1 best-seller for months in 2000. Several stories therein have become part of our American vernacular.

Problem is, it all appears to be wrong. And no one seems to care.

Don't get me wrong, I like Gladwell too. His books are entertaining and they make you think. Getting published regularly in the New Yorker places you in the most elite class of writer. And deservedly so -- if you don't believe me, read this. Brilliant.

But then there's that little problem of him being wrong, a lot.

I first noticed the problem when I read Freakanomics. It's another great book on sociology, written by a science-minded economist (Steven Levitt) and a science-minded journalist (Stephen Dubner) and therefore able to both tell nice stories and back it up with convincing data.

On the cover of my copy of Freakanomics is this endorsement: "Prepare to be dazzled." By guess who? Malcolm Gladwell! Terrific, except the thrust of Freakanomics specifically disproves the prime theory of the Tipping Point. Here's how:

The "Tipping Point" is the critical point where a system can go one way or another. It's where a trend can either take off on a rampage or fizzle out before it gets off the ground. It's where a few small changes can snowball into big effects.

As one example, Gladwell explains the Broken Windows theory that (he claimed) was responsible for fixing the rampant crime problem in New York City in the early 1990's. The idea was to fix little, easy things and the big things will follow (because the Tipping Point will be crossed). So they cracked down on squeegee guys, they cleaned up Times Square, and they put pictures of real windows over broken windows in burnt-out crackhouses so they didn't look dilapidated.

And the crime went down, quickly and decisively. Awesome, right?

Well, science-minded folks are quick to point out that correlations don't imply causal relationships. Just because you did X and Y happened afterward doesn't mean X necessarily caused Y.

This is just the point of Freakanomics. In its most lengthy and controversial chapter, Steven Levitt points out that crime went down everywhere in America, not just New York. And at the same time. And that in various cities and states they were trying various methods of crime reduction from more policemen to curfews to after-school programs to Broken Window strategies, but crime went down the same way, everywhere, regardless. This would seem to imply that none of these factors was the primary factor.

There's only one factor that was common across the entire country: That in 1991 the population of people at highest risk for crime immediately diminished, and that's because in 1973 Roe vs. Wade was passed. In 1973 it suddenly became inexpensive and safe to have abortions, and millions of babies that would otherwise be unwanted and often unsupportable were not born, and did not turn 18 in 1991.

(It's even more compelling than this quick overview. For example, some states legalized abortion earlier than others, and each state saw the decrease in crime 18 years after that state legalized it.)

So back to the main point: That Freakanomics disproves the theory of the Tipping Point, and Gladwell still endorsed the book, and no one seems to care.

Well not no one. Duncan Watts has made a career in network theory, and specifically in debunking the entire "Tipping Point of trends" theory. From a great article in Fast Company:

"It sort of sounds cool," Watts says, tucking into his salad. "But it's wonderfully persuasive only for as long as you don't think about it."

I defer to that article for the fun details, but Watts takes each of the studies Gladwell told and points out how it was either misunderstood or misapplied.

When confronted with evidence like those from Levitt and Watts, Gladwell doesn't even attempt to defend himself:

Duncan Watts is exceedingly clever, and I've learned a great deal from his research. In the end, though, I suppose that I feel the same ways about his insights as I do about Steve Levitt's disagreements with me over the causes of the decline in violent crime in the 1990s. I think that all books like The Tipping Point or articles by academics can ever do is uncover a little piece of the bigger picture, and one day--when we put all those pieces together--maybe we'll have a shot at the truth.

But if you've read Tipping Point, you get the feeling you're being convinced of a theory, not getting a "piece of the bigger picture." To me this is a cop-out, too embarrassing to just say, "Yeah, it's wrong, but at least it had a lot of great stories."

It's this last point that I think saves Gladwell in the end. He is a master storyteller. After being beguiled with interesting, provocative stories, the reader is happy to receive Gladwell's unproven, non-sequitur conclusions.

The stories are so good, they're worth reading anyway. I know I do -- I read Blink cover to cover, the whole while shouting at its illogical conclusions and meandering, self-inconsistent theories, but loving every page and not wanting it to end.

So it's just another way to reinforce Seth's admonishment that marketing should be defined as telling a good story. Sometimes everything else is a second-order effect.

But I know that he knows that I know

When two people in America need to make a boolean decision and a coin isn't available, the go-to method of problem resolution is probably Rock, Paper, Scissors.

Generally people feel this game is fair, meaning there's an equal likelihood of each participant winning, losing, or tying. And of course if you're an academic who believes Big-Oh embodies everything you need to know about algorithms, you might leave it at that.

But we real geeks can never leave things at that. And I don't (just) mean playing Bear, Ninja, Cowboy:

Cowboy beats bear, bear beats ninja, ninja beats cowboy. The theory behind this is that cowboys can shoot bears but are not fast enough to prevent a ninja from assassinating them, but a bear's acute sense of smell prevents the ninja from gaining the element of surprise, thus allowing the bear to maul him. --Wikipedia

So....

The UK-based Telegraph tells us there's a strategy that wins more often than 1/3 of the time:

Research [from the New Scientist] shows that stone, also called rock, is the most popular of the three possible moves in the game.

That means that your opponent is likely to choose paper, because they will expect to you to start the game with stone.

By going with scissors, you achieve an early victory.

But hold on. If rock is the most popular move, going with scissors means you would be defeated. But here it says you'll win. Which is it?

It depends on what your opponent knows. Let's first assume that neither player knows anything about the statistics or analysis of RPS. (Yeah, RPS is not only an accepted acronym, there are even RPS tournaments. Wowzies.) A and B are innocent players, but we want to give A an advantage.

The new study says that, unbeknownst to the players, rock is the most popular move. That means ignorant B will throw more rock than average, so A can win by throwing more paper against it. So we should whisper into A's ear that he should throw more paper.

But what if B has read about this new study? His "beknownst" state has flipped to true. Then we expect B to favor paper, so in this case we should instruct A to favor scissors.

Ah but it gets worse, as it often does with these things. What if B knows that A knows that B read the study? Then B will figure out that A will favor scissors, and will start favoring rock again. Double-fake!

But you see what's coming next. If A knows all of this, A can double-fake too. And so on.

So where does all this leave us? That, at least in regard to this study, he with the most information wins. There's probably a life lesson in there somewhere.

Another life lesson is to always keep digging. Like, this isn't even over yet. One strategy is to call out what you're going to throw, and then actually throw it. The theory is that the other person generally won't believe you. Why is this an advantage? Let's take a concrete example.

A says, "I'm going to throw rock." Let's go with the theory that B doesn't believe it. So B thinks A will throw paper or scissors. If B throws rock, he figures 50% chance to win, 50% chance to lose. If B throws paper, it's 50% to tie, 50% to lose, so that's no good. If B throws scissors, it's 50% to win, 50% to tie. Add it up: B's best move (under his assumption) is scissors, and second-best is rock.

Since A will actually throw rock according to this strategy, and we figure B will throw rock or scissors, A will either tie or win. Awesome!

Until B knows that strategy, of course...

Which leads to the final point, which is that Wikipedia and the ideals of the open source movement of freedom of information has crept far and wide.

Take another look at the image at the top of this post. Nice, right? I didn't make it, I stole it from Wikipedia. It's legal because Wikipedia is good like that. But wait, who made that image? It turns out each of the pieces were stolen from other Wikipedia images and composited together by a guy known to us only by "TheCoffee." Thanks, dude.

Oh, and take another look at that Telegraph article. They stole the image too. Except they didn't credit Wikipedia. They didn't even link to the larger version of the image. Nice, guys.

Freedom at the cost of anonymity.

I'm gonna learn you good

There's been a rash of blog posts lately about how to fix Computer Science education so it teaches real-world, practical techniques instead of being a branch of the mathematics department.

This, in turn, has rekindled the tired debate on whether programming is art or science. Sigh.

I once got to visit a Master Cheesemaker. The term "Master" is not arbitrary. Like other traditional crafts, the (art? science?) of cheesemaking is passed down and cannot be learned by reading a book. The term implies a pedigree of apprenticeship and a level of skill that can be achieved only though years of experience.

Although you can make a passable cheese with information found on the Internet, truly great cheese-making is a process that you have to feel, both with your senses and with intuition. An example, from Wikipedia:

In additional to the craft skills of cheesemaking, cheesemakers also need to be skilled in the grading of cheese to assess quality, defects and suitability for release from the maturing store for sale. The grading of cheese involves the visual inspection of a cheese and the assessment of a sample by sight, smell, taste and texture. The ability to predict when a cheese will be ready for sale or consumption forms part of the cheesemaker's skill, as the characteristics of cheese change constantly during maturation.

Moreover, these skills take years to master:

Most cheesemakers by virtue of their knowledge and experience are adept at making particular types of cheese. Few if any can quickly turn their hand to making any kind of cheese. Such is the specialisation of cheesemaking.

So it's an art, right? Not entirely.

During the tour we saw several stages of the cheese-making process from developing curds to cold-chamber aging, and what struck me was the amount of precision involved. There were thermometers everywhere. Workers checked the numbers constantly -- variations of 5% were enough to kill a live culture or ruin a texture or destroy a taste. Hours of labor and expensive ingredients had to be discarded if something went wrong with step #23. This precision seemed a lot closer to science than art.

So it's a science? No. Because amidst the measurements and process, the Master still had to stick her hand in the cauldron and make sure the curds "felt right."

Does this story sound familiar? Isn't software development a mixture of intuition and measurable steps? Can't we agree that code coverage stats and tight, automated build systems are valuable, but simultaneously we should value beautiful code and code smells?

So perhaps when it comes to computer science education we can take a hint from other crafts. This is the kind of thing you learn from experience. It's not like chemistry which requires experience but also requires a great deal of schooling before you can even start making a difference. We all know that very little of what we learned in school is ever used in practice, yet many of us consider ourselves to be great developers. We must have learned that on the job!

So let's just admit that this is probably the best way to learn. Sure we can do a mixture -- it would help to take a short course on best practices on version control and branching, it would help to practice writing good unit tests, and making Joel's book required reading might be a good start.

But nothing beats writing code next to an expert who is willing to share the "why's" of development.

Tidbits from New Hampshire

Please. Think of the kittens.

Nuggets from the news networks' coverage of the New Hampshire primaries as it unfolded:

Hiliary Clinton bowing out of the next few primaries would guarantee four defeats in a row.

Analysis at its best. Thanks Fox. Why were they even discussing that?

Clinton's flashes of sadness and anger have brought her candidacy a raw authenticity that her aides for years have struggled to manufacture.

Can you manufacture authenticity? Is it bad that "sadness and anger" is the proof that Clinton is "authentic?"

[From Obama's Camp] New Hampshire was Hillary's to lose. Her roots run deep here. As the underdog, anything close to a win by Obama is a victory that will carry into Michigan and Nevada.

[From Clinton's Camp] Anything that's even close to a win is a victory. Barak was up on the polls several days ago, so if the results are close it's because Hillary won the debates, which shows she has the momentum going into Nevada and South Carolina.

Heads I win, tails you lose.

And finally:

America is the greatest country in the world, and not just because of our beautiful landscape, but because of the American people.

Google is not evil... right?

Has Google lost sight of its "do no evil" strategy?

On December 14th, Google decided that every blog post that you've ever shared with a specific person should immediately be shared with everyone in your Contacts list.

As lovingly described on Felipe Hoffa's blog:

No need to opt-in, no way to opt-out. If you didn't react fast all the info you previously shared with your chosen parties could be viewable by everyone you had exchanged e-mails (using Gmail data).

Everyone. Family, friends, people at work, customers, vendors, everyone. Immediately. No choice. Hope you weren't on vacation.

One of Google's (few) responses to piles of angry forums posts was:

We just added a new option for those of you wishing to rearrange your sharing habits in light of the new features.

Seriously?

And it's still not fixed.

As Google collects more and more info, we must trust them more and more. And so long as Google retains its Benevolent Dictator status, the benefits probably outweigh the possible disadvantages.

But their insistence on this subject could be a bad sign. Mistakes are fine so long as you admit them and fix the problem. JetBlue's delay debacle took them from being at the top of customer satisfaction ratings in 2006 to being removed even from consideration in some 2007 satisfaction polls. Today JetBlue is back at the top of customer service ratings. Why? Because they turned what could have been disaster into an opportunity to demonstrate that, no really, they are concerned with customer well-being, and they immediately went on the record saying so and explaining how they will ensure that type of problem never happens again. And they did what they said.

Google is in the same position now, but they have just the opposite response. Facebook capitulated; Google needs to also.