Mount Diablo Tarantulas

As I was biking up Mount Diablo the other day, I came across an animal I'd been keeping an eye out for: a male tarantula in wanderlust. They're easiest to spot as they cross the road, and this one was quite determined to get to the other side.

In the fall the male tarantulas set off in search of females to mate with. If she doesn't eat him (which she'll only do if she's famished) he'll keep looking for partners until the cold weather, or a hungry lover, gets him. Females, on the other hand, can live up to twenty years.

I've always liked spiders but this one was wary of me and wouldn't stay on my hand. That's OK :-)

This article has more information about these fascinating creatures.

A Visit to Mojang, Makers of Minecraft

This summer my Minecraft-mad boys (aged 12, 10, and 10) got the thrill of their lives: a visit to Mojang and meeting Notch, its creator. If you've never heard of Minecraft, it would be hard to know where to start except to say that it's an amazing game that fosters a ton of creativity and deservedly has an astoundingly vibrant community. Hopefully, there were enough superlatives in the last sentence to make you want to check it out :-)

Visiting Mojang is no easy thing: these guys are extremely busy and well, they're in Sweden while we live in California. The geographic challenge was overcome when my wife Katrine took our sons to Norway to visit relatives. Stockholm, home of Mojang, is but a 6 hour train ride from Oslo.

Over to Katrine:
As they so wanted to visit their Minecraft Heroes, the boys sent personal letters to Notch to accompany the Minecraft newsletters they had created as homeschooling projects. I followed up with a phone call and emails to Carl, the CEO. He invited us to visit on one of their gaming Fridays. He emailed me the code that opened the door to get in the building, that was pretty cool! Carl showed us all around the Mojang office, we met the Scrolls crew in a separate area where we  couldn't take pictures, and other Mojang'ers with Notch in another room decorated with the soon-for-sale wallpaper. 
They made us feel really welcome and special, and even though Carl was going on vacation the next day, he had time to show us around, talk to us and introduce us to his colleagues. He invited us to play games in the orange game room, and just hang out as long as we wanted.

Thomas, Alexander, and Daniel meet Notch. Not always easy to smile when you're meeting your hero :-)
Daniel shows Notch and Carl the winged chest plate mod he & I coded together in Java (lets you fly by jumping and fall to the ground like a feather).
Alexander shows Carl some of his Minecraft constructions.
Cool artwork!
Throughout the visit, Notch, Carl, Jens, Daniel, and the rest of the team were really welcoming and kind, and Notch even smiled non-commitally when our Daniel told him he should include the winged chest plate in a future version of Minecraft! ;-)

See you at Minecon! (Look for 2deckalex, 2deckdan, 2decktom, 2deckmom, and 2deckpaul at a minecraft server near you :-)

Belgians Love Android

OK, you may not think so, but when our waiter put this pot of steaming mussels in front of me the other day in Belgium, I couldn't help but think: "Boy! That really looks like the Android mascot!"

Come on! You can see the resemblance right?

No?! How about now? :-)

The Cathedrals and the Department Stores

I've been pondering mobile platforms lately, particularly Apple's iOS walled garden vs. Android's open platform. Owning iPads 1 & 2 and having recently switched to a Nexus S phone running stock Android Gingerbread, it's been interesting to compare the experience that each OS provides.

Let's start with one of the first things that hit me: Steve was right. When Jobs adamantly refused to allow flash on his devices many people (myself included) saw this as little more than a spirited defense of the walls around Apple's garden. I still believe that was a significant part of Apple's thinking, but on the first day I had my phone Steve's argument that flash's user experience was terrible on mobile hit home.

He was right! It didn't take much time surfing the web on my Nexus before I hit a site using flash and was invited to download the player from the Android market. Well, flash... leaves much to be desired. Running animations and video dramatically slows down responsiveness, way more than video encoded with H.263, Apple's alternative. Yes, I could now view the content, but the experience was a disappointment.

The more I used Android, the more I understood the value of iOS' walled garden and focus on user experience. Again and again, things you have to manage on Android just work on iOS. For instance Android gives me the battery consumption of all services running on the phone and allows me to force close them. On iOS? Nothing. You expect the apps to work properly and they pretty much do. Apple's framework makes it a lot harder for developers to hog resources or impact usability. Yes, it hampers devs a little too, though that clearly hasn't prevented over 400,000 apps from being written.

All this reminded me of that old article, The Cathedral and the Bazaar. In it, author Eric Raymond posits that the Windows "cathedral" (monolithic, slow moving, unwieldy, and, obviously, yucky) is doomed because the Linux "bazaar" (vibrant, innovative, fast paced, and, clearly, cool) can't help but overtake it. Roughly 15 years on, I'd say the results have been mixed: Linux mostly won on the server, definitely won in the appliance / embedded category, and failed on the client side.

Today few worry about Microsoft the way we used to. The cathedral these days is clearly Apple, and it's a much more invasive cathedral than MS ever was. Apple has a very long reach: they own the hardware, the OS, control what you can do on the OS (at least on iOS), the distribution mechanism (App Store), much of the content (iTunes, and the 30% "tax" on 3rd party subscription services), and soon storage (iCloud). Oh, let's not forget they own the tablet space. And to top it all off, Apple rules from a design perspective: Their products set the standards for the industry.

Focusing on the iPhone and extending the metaphore, I'd argue that Apple has two cathedrals: AT&T and Verizon. The buildings are in different parts of town, and you have to sign slightly different agreements to pray there (yes, pray). Once you're inside, though, almost everything is the same. From a user's perspective you don't identify with the location of the Cathedral (the carriers) you identify with what's inside it (Apple). AT&T and Verizon compete against each other by convincing you that their part of town is nicer.

What about Android? Well, it's clearly no bazaar. There's no PC-equivalent of a cell phone that manufacturers compete to build and that you then install Android on. Moreover Android development is largely done by Google. Instead of a cathedral, each manufacturer of Android handsets is more like a department store. That means they compete primarily by adding floors (i.e. new hardware capabilities, like a 3D screen in the latest Evo), and redesigning the interiors (i.e. adding customizations on top of the stock Android, like Samsung's Sense UI). And, in contrast with the iPhone cathedrals, each carrier neighborhood has a few department stores to choose from.

This gives users more choice at the expense of confusion and usability. The custom UIs and different revisions of Android make both picking and using a phone harder than it should be.

The situation is much worse for developers. It is easy to develop for iOS devices. There are only a handful of devices to choose from, they experience each provides is extremely consistent, and the development tools excellent.

Not so for Android: While browsing the Android Marketplace I was struck by the many apps stating which phones they do / don't support, and the number of one or two star reviews along the lines of "Your latest updates sucks, now the app won't start! Evo 4G" or "Crashes randomly on DroidX, please fix".

Google is recreating the fragmented market we had in the early Windows years when fiddling with device drivers, TSRs, and config.sys files were the norm. (Apparently, version 4 of Android, aka Ice Cream Sandwich, will address some of these issues).

Despite this I really like my Nexus S phone: The voice commands are amazing, the notifications are refreshingly useful (Apple's finally fixed this in version 5), maps & navigation rock, and, as a heavy Google user, the integration with Google's many apps is excellent. In my opinion Android's features today are more advanced than those of iOS.

However all this comes at price: having to manage battery life & services much more closely, and the occasional reboot to kickstart "dead" services. 

If someone told me they wanted a phone, tablet, or even computer today, I'd be hard pressed not to recommend an Apple product.

Looks like the Cathedrals are winning.

Most of my blog posts are written in small increments over a few weeks or months. This post was finished a couple weeks ago while on vacation in Belgium. With impeccable timing, Google made a very important announcement on Monday: the acquisition of Motorola's Mobility division, i.e. their cell phone manufacturing arm. This has a number of interesting angles (esp. with regards to patent acquisition) but as far as this article is concerned it signals something important...

Google's going to build cathedrals of its own.

Taming Software Complexity

Complexity is everywhere in our world: In our ever-growing canon of laws, in the volatile & unpredictable nature of the stock markets (esp. now with the abundance of autonomous trading systems), in our tax codeand of course in the second law of thermodynamics. It's little wonder then, as programmers the world over know, that complexity is definitely present in our software. Of all the long term threats to applications, complexity is perhaps second most critical (the first being no longer meeting user needs :-).

(Complexity can be beautiful too. Source)

Unfortunately, complexity goes hand in hand with success: the more popular an application, the more demands that are placed on it, and the longer its "working life". Left to their own devices both factors will increase complexity significantly. Life for a mildly successful app is even worse, the low demand usually results in a never-ending "maintenance mode" where poor code stewardship often abounds.

Without ways to tame complexity, any evolving piece of software, no matter how successful, will eventually collapse under the load imposed to simply maintain it.

How is software complexity defined? Many techniques have been proposed, from simple approaches such as lines per method, statement counts, and methods per class, to more esoteric-sounding metrics like efferent coupling. One of the most prevalent metrics in use today is cyclomatic complexity, usually calculated at the method level and defined as the number of independent paths within each method. Many tools exist to calculate it, at RelayHealth we've had good success with NDepend.

Identifying areas of complexity in the code base is easy. The hard part is deciding what to do about them. Options abound...

Big Ball of Mud
The "Do Nothing" approach is always worth exploring and it typically results in Brian Foote's Big Ball of Mud. Foote wrote the paper as, however noble the aspirations of their developers, many systems eventually devolve into a big, complex mass. He also notes that such systems can sometimes have appealing properties as long as their working life is expected to be mercifully short. Fate often intervenes though and woe betide the programmers stuck maintaining a big ball of mud.

Creating a big ball of mud is easy, just add code and mountain dew :-)

Let's assume that you'd like to stay out of the mud. What other options are there?

Some simple process changes can help fight complexity:
  • Analyze code metrics upon checkin and reject the new code if the files changed don't pass complexity targets (this will initially slow down development if  you impose it mid-flight but it will improve your code quality).
  • Allocate bandwidth for complexity bashing: reserve capacity such as 1 sprint every release, or a %age of total story points (e.g. 20% of all completed story points every month).
  • Temporal taming: Focus on different parts of the architecture over time, say a new area every month.
  • Something I've been wondering about: Are there processes that promote complexity? Or are some so time consuming that they prevent developers from addressing complexity?
  • Automation is a powerful tool. You can easily add exceptions to a manual process ("Oh, well if it's an app server in cluster B, then we need to run this additional program") but an automated process is a lot harder to complexify, and if it needs additional steps at least you'll know their execution will be consistent.

Complexity has spawned many solutions at the architecture / software engineering levels, though even something as basic as ensuring developers all have a common understanding of the architecture and documenting its basic idioms can go far. Other solutions are very well covered in our industry:
  • Design patterns. Tried and true approaches to common problems.
  • Aspect Oriented Programming. AOP's focus on abstracting common behaviors from the code base can reduce its complexity.
  • Service Orientation. Ruthlessly breaking up your applications into disparate, independent services reduces the overall complexity of the system. This is an SOA approach but without the burdening standards and machinery that armchair architects are prone to impose. One of my favorite examples of this approach,, has been using SOA since before anyone thought up the acronym. By creating loosely coupled services with standard interfaces it's much easier to update or completely replace a service compared to the same work in an inevitably intertwined monolithic application.

The most powerful weapon against the encroachment of complexity is culture: the shared conviction among developers that everyone needs to pitch in to reduce it.
  • Refactoring: developers should feel empowered to refactor code that's overly complex, not in line with the evolution of the architecture, or simply way too ugly. Two key enablers are required and both need a strong cultural buy-in:
  • A solid set of unit and other tests so the developers knows if they've broken something
  • A fast build & test cycle. Most developers like to work in small increments. Make a small change, test it. If it takes 15min for a build & test cycle, very few developers are going to refactor anything that isn't directly in their path. I really like the work Etsy has done in this area as well as culture in general by focusing on developer happiness
  • Adopt this maxim: "Leave each class a little better than when you found it". Even if it's a small change - adding a comment, reformatting a few lines of code - taken in aggregate these changes really add up over time.
  • Remove features. I heard one of Instagram's founders state that they spend a good deal of time removing features as well as adding them. That was probably a slight exaggeration, but removing features can be very powerful in terms of fighting complexity: both directly (fewer lines of code == lower complexity, except with perl ;-), and indirectly as a signal to the team and your customers.
  • What have I missed? I haven't written about complexity as the database level though, while we're on the topic, I suspect that however much I like NOSQL databases, their rise will increase data complexity in the long term. The leeway many provide developers in storing information will make it very hard to manage it: data elements will be needlessly duplicated, inconsistencies within elements will abound, etc. Error recovery will be critical, as will a strong business layer to help provide consistency.

    (Another source of complexity! Source :-) 

    Happy simplifying!