You know you've been coding too much lately when...

...this brilliant comic for SQL geeks cracks you up. (Scarily, it also reminds me of something my team needs to do soon!). If this is all gibberish to you, congratulations, you still have a life :-).



xkcd - A webcomic of romance, sarcasm, math, and language - By Randall Munroe

7 reasons I switched back to PHP after 2 years on Rails - O'Reilly Ruby

7 reasons I switched back to PHP after 2 years on Rails - O'Reilly Ruby:

PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER

That is how Derek Silvers concluded his article over on O'Reilly about a bad experience trying to rewrite his existing PHP site in Rails. How true!

Another key message from Derek's column, though he doesn't say it directly: there can be tremendous value in refactoring, and refactoring does not require porting or changing platforms. All modern languages and platforms are capable of supporting large scale high quality systems. Sure, there are differences, and pros and cons, to each for various applications. But those differences are in the noise compared to the differences in capabilities of architects and developers themselves.

The lesson to me is: if you have a day to spend to make things better, do you invest it in learning a new language or platform, or in improving your own skills? I invest that time in myself. Advantages from switching platform or language can be had, but those wins are usually longer term, and can be undermined by abandoning some of your previously built skills and fluency.

Community Building isn’t about Features - Bokardo

Thank you, Josh Porter, for the concise summary of the Businessweek article "Ten Ways Flickr Builds Communities".

Community Building isn’t about Features - Bokardo

Happy unlaunch day at Like It Matters

I liked Brian Oberkirch's mini-rant yesterday, on "putting your head down and executing on ideas that delight the people your app is really made for," rather than cultivating flash and hype. But what topped off his entry for me was his update at the bottom:

Happy unlaunch day at Like It Matters:

[update: OMG, I almost forgot an important sidenote. Too much horserace guy attention at the wrong time may kill you. Witness the 2 year debacle that is Flock. Ill-timed hype & expectation building made their time to experiment disappear and probably killed a potentially very interesting project. Instead, be like Threadless. Do awesome things, and eventually, media will figure out that what you’re doing is cool. By then, you are far enough long that they are less likely to screw you up.]

When dealing with misguided marketing and PR folks, it is not enough to simply say you want to execute and avoid hype. You have to say *why*, and this is exactly why. Hype and attention are indications that expectations of your business have already been set. These expectations are close to impossible to undo. If you are not completely sure what your winning business or technology strategy is, you absolutely have to preserve your ability to change. Premature expectations will inhibit your ability to change and adapt.

MashupCamp--a new kind of get-together - | CNET News.com

Nice summary of MashupCamp by CNET's Daniel Terdiman over on news.com. I like this quote:

"The amazing thing about these camps, using open space methodology, is they shouldn't work," said Ross Mayfield, CEO of Socialtext, which makes social software for collaboration. "Like a wiki, it turns out that some very simple and open rules have shockingly positive results--because people, on the whole, are good. Open events like these have become almost commonplace in the Valley. In fact, I'd say they are a key driver for the current wave of innovation. One part wiki, one part space and two parts people, add water, and voila!"

This gets at what I appreciate most about the emerging Web 2.0 & mashup culture: you hear "client SDKs talking to APIs", but what's really happening is "developers talking to platform providers, other developers, users, and anyone else, all eye to eye." This is the most openly social, collaborative, and peer-to-peer development that I have seen in 25 years of coding, and I sure hope it sticks. Coding can be really fun. If it were not for these emerging social changes in software development, I don't think I would care nearly as much for the Web 2.0 world.

MashupCamp: costs of API support

In yesterday's "Why Mashups Fail" session facilitated by Anil Dash, there was a brief discussion of the cost to the platform providers of hosting open APIs. David Berlind chimed in that one of the major web platform providers has bean counters who claim a $0.07 per call cost, to a chorus of "this is a an API bubble" and "this is not sustainable".

It sounds bad, but maybe we need to look more closely at how we characterize the costs of open API support. First, these APIs are targeted at open ended use by developers and early adopters. They are essentially a playground for unconstrained (well, less constrained) innovation and creation, well suited to allowing good ideas to see the light of day. They are also good for allowing bad ideas to fail, and fail quickly, which is a good thing since early failure leads to faster learning. When the good idea matures to where it is deemed worthy enough to bring to the mainstream masses, I fully expect the platform provider to do what it takes beyond the existing developer API implementation to support it in a cost effective manner (i.e., one that scales to the many millions of mainstream users). I would not predict the mainstream application per-call costs from those of the developer API.

Second point is that through their open APIs and platforms, the big providers are subsidizing innovation and creativity outside of their companies at much lower cost to themselves, and with lower risk, than they could do it internally. The cost of the developer APIs may be better seen as leveraged R&D than simple operations, in which case maybe it should be valued differently.