January 2006

« December 2005 | Main Index | Archives | February 2006 »

27
Jan

Atlassian has recently become a victim of the poker craze that's been sweeping the world. After five hard-fought night-time games (a worry, since after the next we run out of Star Wars movies to name them after), and two winner-takes-all lunchtime lightning tournaments, it was decided that what we really needed was a leaderboard.

What happened next should be pretty obvious to anyone who runs a wiki at work. An email was sent around the office directing everyone to a page on our extranet into which they could record their winnings (or losings) for each night, and rankings in the lunchtime tournaments1.

A note to my readers: much of what follows will sound like marketing material for my employer. Normally this is a subject I avoid on my blog, because the one thing that almost all rah-rah my-software-rocks isn't-this-cluetrain-thing-cool blogs have in common is that they bore me to tears. So don't worry, I'm not making a habit of this, I just felt that in this particular case (and maybe one sequel), I had something interesting to say.

While I was adding my details to the page (after taking part in three games, I'm $25 up) I was left wondering: what would a company without a wiki do2? In the mood to beat around a few straw men, I came up with a few alternatives.

1 Somebody tabulates all the scores into an Excel document and sticks it on the share drive, where it quickly gets lost amongst all the other spreadsheets.

2 The local Notes™ guru spends all afternoon on an application where everyone can enter their winnings or losses into a Notes database, and have the results nicely formatted... or more likely the guru says this is what he's going to do, but finding the spare afternoon isn't as easy as he thought.

3 The company's Intranet gatekeeper has everyone email him their scores, and puts them up on the web. Six months later, he has a mail folder full of pending updates that he hasn't quite had time to process yet because he has a dozen servers to keep running, and poker isn't exactly on the critical business path.

OK, so you get the idea. But it's only poker results, right? It's not like it's anything particularly important to the company that would justify the existence of the wiki.

Except it is, and it does, because our poker standings page on the extranet represents, in a microcosm, every little bit of information that a company's employees think is worth writing down, if only there were a convenient place to do so. This is one half of the corporate wiki's raison d'etre, and is the reason that so many of our customers tell us how quickly "Just put it in Confluence" and its converse "Look for it in Confluence" have become almost cliché in their organisation.

Wiki is a subversive technology.

If you'd asked anyone ten years ago what would happen if you put a website online that anybody could edit without restriction, I doubt the answer you would have got was: "It will go on to become, for a while, one of the most interesting places to discuss software engineering, and spawn thousands of similar sites, including a million-page, surprisingly accurate free encyclopaedia."

Wiki works because it breaks down established roles: the distinction between writer and reader, between the consumers of information and the information gatekeepers. This is why the wiki had to originate outside the existing ecosystem of corporate knowledge management applications. Companies write software that reflect their own structure, and wikis succeed on their ability to create their own structure.

This is part of the reason that it's difficult to cold-sell a wiki to a company. The successes of public wiki sites help (for those who have heard of them), but the selling-point of a wiki is the readiness of people to work with one once it's there, something that's really hard to explain a priori. (Which is why we love seeing people upgrading their licenses. It's proof that the wiki is virally taking over.)

Writing an enterprise wiki is a balancing act. To a large extent, the impetus of the business will be to turn the wiki back, piece by piece, into the rigid document management systems it replaced. If you keep acceding to their wishes, you'll end up with something that is, once again, too much of a hassle for anyone to want to keep their information on.

Some battles, of course, you can't fight. The first thing a business will look for in a product are its security features, so having a decent permissioning system is almost a given. Still, I do my best to recommend that the most beneficial thing one can do with such a system is to use it as little as possible.

In the end, of course, the trick is to try to look beyond the feature being requested to the problem that the user wants solved. If it is truly a problem, and not a case of "that's just not how we do things around here", there will probably be a wiki-friendly way to solve it.

1 It turns out that while he's never been the biggest winner on any one night, Mike has been the best player overall, never leaving with less money than he arrived with. I'd suspect that poker nights were part of a subtle plan to recoup a portion of our wages, if it weren't for the fact that we more than make up for it by drinking the office beer.

2 Sadly, the acronym WWACWOWD? is just not catchy enough to market.

Randy MacDonald on the pragprog mailing-list, regarding choosing programming languages that "make you think more"

I'm not sure "made me walk more than any other car I've used." would be complimentary.

An exchange between Aiden Rogers and Steven Rogers on the rubycocoa mailing-list:

(Aiden) Does anyone have any suggestions on how to obfuscate a RubyCocoa application?

(Steven) Write it in Perl?

An aside about RubyCocoa, the framework that allegedly allows you to write Mac OS X applications in Ruby.

I say "allegedly", because in order to multithread a RubyCocoa app effectively, you have to apply an unofficial, hard to get hold of source patch to the Ruby interpreter and recompile. This makes developing and distributing a RubyCocoa application particularly messy, to say the least, unless you want to be stuck with an unresponsive toy app that does everything in the main UI thread.

My fantasy announcement for this year's WWDC would be that Apple was going to start supporting one of the scripting-language bridges (either RubyCocoa or PyObjC) as an official strategy for the platform.

The much maligned Cocoa-Java bridge was never a good idea: partly because the statically-typed Java language was such a bad fit for the pervasively dynamically-typed Cocoa framework, and partly because the Java language itself isn't really that much of an improvement over Objective C.

Either Ruby or Python would be a much more natural second language for Cocoa development. Their dynamism makes them a great fit for the framework, and they offer significantly enhanced developer productivity over Objective-C, only having to drop down to the lower-level language for performance-critical sections.

I can dream, I guess.

My descent into emoticon hell took some time. Back when I spent almost all my Internet days on Usenet, I would pride myself on not having succumbed to the need to pepper my communication with smileys. Later, I took the same attitude with me to IRC (largely because I was introduced to IRC by the friends I'd made on Usenet). I can't remember at what point after venturing beyond those circles I became addicted to unnecessary punctuation1, but it has now reached a point where I can't say anything over chat or instant-messaging that's even remotely meant in the slightest hint of jest without appending a fucking ':)' to it. Worse, the disease has spread even to my less formal emails.

Tonight, however, was when I knew I was completely gone. After writing on my blog the sentence "Consider the near-inevitable failure of your company as the price you pay to make tomorrow a better place for us all", I found myself agonising to the point of losing sleep over whether I should have appended a smiley to ensure everybody knew that yes, I understood the implications of what I was saying, and that it was meant as a joke.

A small corner of my brain rebelled:

"Shouldn't that be obvious to any reader with more than two brain-cells to rub together?"

"Well, yes. But why not just put a smiley there anyway, just in case?"

"Because written English survived quite happily for centuries without needing punctuation to delineate humour. I can almost understand why it might be necessary in back-and-forth conversational one-liners, but I don't see why we have to start corrupting honest prose just because some readers are getting too used to being spoon-fed joke-markers to work it out for themselves."

"You can be a real bastard, you know."

"Deal with it. I'm your brain and you're stuck with me."



1 Well, that unnecessary punctuation in particular. My predilection towards cramming as many commas into a sentence as I can has been around much longer.

When I first visited Flickr back in February 2004, the site was primarily Flash-based IRC-style chat. There were social-networking-style features to keep you in touch with your friends, there were 'groups' to find people with similar interests, but the main focus of the site was the chatrooms. Flickr was, as far as I know, the first non-pornographic social networking service that allowed the networkees to interact in real time.

I'd been directed to the site from an IRC channel, so my obvious response was "Hey, we're already talking over there, why do we need to be talking here as well?" The only novel feature I could see was the 'shoebox' of images that you could upload to the site and share with other members, or paste into conversations.

The way things turned out, it looks like I wasn't the only user who thought that way.

Which brings us, in a round-about kind of way, to Joel Spolsky's advice to anyone looking to start a business:

Don’t start a business if you can’t explain what pain it solves, for whom, and why your product will eliminate this pain, and how the customer will pay to solve this pain.

Plausible advice, and I've said similar things myself in the past. But as Cameron points out, it's not necessarily good advice:

By the time you can explain what pain it solves, for whom, and why your product eliminated this pain, and how much the customers were actually willing to pay to solve this pain, the best years of the market will be behind you.

Joel himself doesn't seem to have followed his own advice when founding Fog Creek Software:

Fog Creek Software started in September 2000 based on the simple idea that if we built a company that was a great place to work, we would be able to attract great talent. And once we had great talent, we could succeed at just about any software project we found interesting.

In a linked article, he goes on to express his distrust of business models built around the idea for a product:

The trouble with build-a-better-mousetrap is that there's not a lot of evidence that it works. [...] There's a different way to think of software development. Imagine that the goal of your software company is not to solve some specific problem, but to be able to convert money to code through programmers.

Joel's latest advice still makes sense if you take "start a business" to mean "devising a product". It is a very good idea to know what pain you're creating the product to alleviate. Even then, though, it's a dishearteningly conservative approach. del.icio.us didn't solve any identifiable problem, it was just cool because it existed, and because lots of people joined in and found interesting new things to do with it.

Of course, hoping to come up with the next cool thing that solves problems even you didn't know were there when you started isn't necessarily the safest of business propositions, but if nobody did it then our industry would be entirely bereft of innovation. Consider the near-inevitable failure of your company as the price you pay to make tomorrow a better place for us all.

When you're building a business rather than just a product, though, you're much better off asking yourself what your survival plan is when your great founding idea tanks, or when (as happened to Flickr) you have to turn it 180° because the market has told you that you should be barking up this tree instead.

When does the following code not throw a NullPointerException?

MyClass obj = null;
obj.doSomething();

This one came up on the Apple java-dev mailing-list the other day. The answer (in case you haven't guessed) is: when doSomething() is a static method of MyClass.

It's pretty obvious when you think about it. The doSomething() method call gets compiled into an <a href="http://java.sun.com/docs/books/vmspec/2nd-edition/html/Instructions2.doc6.html#invokestatic">invokestatic</a> bytecode. invokestatic doesn't need an object reference on the stack, so after compilation the obj variable isn't even being doesn't even need to be referenced any more, let alone dereferenced.

This sort of language trivia is unlikely to be useful to anyone not just about to go into a certification exam, or entirely the wrong kind of programmer interview. It's just one of those mildly interesting edge-cases, like what happens when you throw null, or the maximum number of parameters you can pass to a method, or how to change the value of a constant string.

If you find yourself in a situation where have to know the answer to any of these questions, turn around and run.

It's not raining tonight. Rain is something that starts in the sky then falls down until it hits the earth. The weather I can see outside my window is just humidity reaching its natural conclusion and becoming too heavy to stay where it is. It's not raining tonight; the mist has just discovered there's only a little way left to fall.

The other day I ordered upgrades for iLife and iWork, on the grounds that I'd end up buying them anyway and there was no point putting off the inevitable.

I ordered them together, but they arrived (at the same time) in separate boxes, like so:

I wonder, since online shopping really started taking off, how much money and effort has been expended shipping plastic bladders full of air around the world?

The Unofficial Apple Weblog took this photo of a 1985 hard drive at Macworld: $40,000 for 40MB, and... big:

(Admittedly, this has been exaggerated for promotional effect. The Mac II, introduced in 1987, only cost $5500 with a 40MB hard drive included. But still, we've come a long way.)

Cory Doctorow:

Follow the storage performance/size/capacity/price trendline out 10 or 15 years, and we get to the hard-drive that John Gilmore's been describing: the size of a sugar-cube, costing $1-2, powered off of the occassional hard shake, and capacious enough to store every word ever uttered, every song ever sung, every painting ever painted, every movie ever shot, and every word ever written, at a resolution that can be magnified into the microscale without distortion.

My prediction is that even then, we'll still complain about running out of disk space, and we'll still be too lazy to do backups properly.

Story one:

It's the morning (Sydney time) after the Steve Jobs Macworld keynote. The streaming video of the event has been put online, and your humble narrator decides to watch it before going to work.

About twenty minutes into viewing the keynote, the rest of the world discovers the stream, and despite the best efforts of the edge-server network, the video becomes choppy and unreliable. Three or four minutes later it stops working entirely, and the video can only be watched in twenty second chunks, followed by a minute or two of rebuffering, clicking and swearing.

Story two:

It's morning (Sydney time) after the Steve Jobs Macworld keynote, and the video of the event has just been put online for download. Your humble narrator starts the download just after he wakes up, then goes to have a shower, make a cup of tea and make breakfast.

After the first twenty minutes of the video has downloaded, everyone else discovers the video, and download speed starts to slow to a crawl. Charles finishes his toast, and decides to copy however much of the video has finished downloading by the time he leaves to his Powerbook, and watch it on the way in to work.

Story three:

It's morning (Sydney time) after the Steve Jobs Macworld keynote, and the video of the event has just been put online for download under a Creative Commons license (attribution, no derivitive works, no commercial use). By the time your humble narrator wakes up, the video has already been converted into a torrent.

The download starts slowly, but after a while more and more people start to discover the torrent, and thanks to the multiplicative effect of peer-to-peer sharing, it soon comes close to saturating Charles' 14Mbit ADSL link. By the time he finishes breakfast, he has the whole thing downloaded. He leaves the torrent running in the background as a courtesy to others who might want the file.

Now: rank these three stories in order of how much they benefit Charles in that he gets to watch the video in the most convenient form, and how much they benefit Apple (weighing the loss of absolute control over the content vs the largely promotional message reaching consumers in a less frustrating manner).

Kevin Marks is right. When interaction is not required, downloading is always better than streaming. (and on a video blog post here)

Tom Bridge explains the Macworld San Francisco keynote to non-believers:

So, Steve will go on and tell us why it is that these new things are wonderful, how well they compare to other products, and then also what they will set us back. The former makes the latter palatable. Everyone in the room will create a reason why the new prices are A) acceptable and B) worth taking out a second mortgage or a home equity line of credit. It's not that we're brainwashed, it's just that the pitch is so good. Steve could sell rollerskates to velociraptors. It's what he does. Generally, though, he's on the ball. He wouldn't do this if he didn't believe it himself. It's why Apple is still here.

Apple makes technology cool. They make computing cool. This is why they hold such high esteem with many geeks. They make what we do into something that can get us laid. I realize this is trite, I realize this is clichéd, but it's also true. Windows guys are boring. I'm sorry Scoble, you just are. You try to think you're cool, by pointing out all our flaws, about how you're so much better than we are, about how you're in more places, and doing more things. But really, all it does is make you look bad, and us look oppressed and "dangerous" to the womenfolk.

Next year, I'm going to have to find some excusereason for the San Francisco office to really need me to be in town in January.

The banner-festooned slogan for the Festival of Sydney this year is 'This is Our City in Summer', which can lead to a certain level of signage-irony when it's pissing down with rain.

Happy New Year

  • 12:43 AM