Geek It Happened to Me

Lost Conversations #4: A Resounding Yawn from the Developers

Lost Conversations is the title of a series of blog entries that have

been sitting in draft form for too long; it’s my attempt to do some

“spring cleaning”. This is the fourth in a series — the other three are:

Please note: this one’s rather high in technical content. It’s also been cross-posted to The Farm.

Hindsight, Guy Kawaski and Ice

One of my favourite speeches is a high school commencement address titled Hindsight, which was made at Palo Alto High

School by one of my role models (especially given my line of work):

former Apple evangelist Guy Kawasaki. It was a “top ten list” of

advice to the graduating class, and item number eight was “Challenge the known and embrace the

unknown”. It went like this:

One of

the biggest mistakes you can make in life is to accept the known and resist the

unknown. You should, in fact, do exactly the opposite: challenge the known and

embrace the unknown.

Let me tell you a short story about ice. In the late

1800s there was a thriving ice industry in the Northeast. Companies would cut

blocks of ice from frozen lakes and ponds and sell them around the world. The

largest single shipment was 200 tons that was shipped to India. 100 tons got

there unmelted, but this was enough to make a profit.

These ice harvesters,

however, were put out of business by companies that invented mechanical ice

makers. It was no longer necessary to cut and ship ice because companies could

make it in any city during any season. These ice makers, however, were put out

of business by refrigerator companies. If it was convenient to make ice at a

manufacturing plant, imagine how much better it was to make ice and create cold

storage in everyone’s home.

You would think that the ice harvesters would

see the advantages of ice making and adopt this technology. However, all they

could think about was the known: better saws, better storage, better

transportation. Then you would think that the ice makers would see the

advantages of refrigerators and adopt this technology. The truth is that the ice

harvesters couldn’t embrace the unknown and jump their curve to the next curve.

Challenge the known and embrace the unknown, or you’ll be like the ice

harvester and ice makers.

You Couldn’t Give Away Visual Studio Here

A couple of weeks back, I placed an order for the beta evaluation version of Microsoft

Visual Studio 2005, which consists of the upcoming version of the

Visual Studio IDE, the Visual Studio Team Server (which I assume is

some software to assist with versioning and collborative programming)

and Microsoft SQL Server 2005. For those of you who aren’t terribly

into techie stuff, this is the Microsoft equivalent of a fully loaded Snap-On Tools truck, minus the free calendars with the girls in bikinis holding wrenches.

I received the discs a couple of days after placing the order and


sent out an office-wide general notice to my co-workers saying “Hey, if

you want to try out the Visual Studio 2005 beta, come by my desk and

I’ll loan you the discs.” Not only is it my job to make sure that the

tech world is aware of what Tucows is doing, it’s also to ensure that

Tucows is aware of developments in the tech world.

The response: almost none, save for two comments.

One comment came from a sales engineer who passed by my desk and said “Heh. Good luck getting anyone interested in that.”

The other was a short and perfunctory email from the IT department

reminding me that it is a violation of company regulations to install

unauthorized software onto company machines.

(Of course, the joke’s on IT — I brought in my own Windows box. As

someone who isn’t in the development department of the company, I got

issued a non-developer machine. It’s quick enough for writing TPS reports,

but not up to the task of development. I use it as a monitor stand. I

did what any half-decent hacker would do — I brought in my own box.)

COBOL for the 21st Century

Of course, I installed Visual Studio 2005 on my machine. A number of

our customers build their web services on the Microsoft platform and I

should at least maintain some passing familiarity with Windows

development (in a former life, I wrote VB apps for small-to-mid-size

businesses). I wouldn’t be doing my job if I didn’t install it and

build some basic apps, both desktop- and web-based.

However, for the development of the Tucows platform — our domain name

registration service, email and email defense, Blogware, Blogrolling,

Start — there is no compelling set of reasons to switch from the LAMP


On an even more fundamental level, there’s a reason for a lack of

interest in Microsoft’s languages (C# and Visual Basic) and even their

Sun-based kissing cousin, Java: they’re not where the interesting stuff

is happening.

C#, Visual Basic and Java are going through an “ice maker” or “ice

harvester” phase. The improvements to these languages are now

incremental and seem to be aimed at making sure that they have more

items on their feature lists than their rivals. Improved IDEs? Nice,

but nothing major. Generics? After trying to improve away from C++,

both C# and Java went back and aped the unwieldiness of C++’s

templates. These new features are knowns; they’re the software

equivalent of ice harvester thinking: faster ships, better ice storage,

sharper saws.

The really interesting stuff is happening with open source dynamic

languages, namely PHP, Python and especially Ruby, all of which are

pushing little-known possibilities of programming, such as

metaprogramming, generators, higher-order functions. These languages

are more about getting things done and less about getting in your way.

Consider the difference between the code required for the Order class

in this developerWorks article. In the Java version, you need this XML:

01 <hibernate-mapping>
02 <class name="models.Order" table="ORDERS"
03 dynamic-update="true" dynamic-insert="false"
04 discriminator-value="null">
06 <id name="id" column="id" type="java.lang.Long"
07 unsaved-value="null">
08 <generator class="identity"/>
09 </id>
11 <set name="items" lazy="false" inverse="false"
12 cascade="none" sort="unsorted">
13 <key column="id"/>
14 <one-to-many class="models.Item"/>
15 </set>
17 <property name="name" type="java.lang.String"
18 update="true" insert="true"
19 access="property" column="name"/>
20 </class>
21 </hibernate-mapping>

…and this Java code…

01 public class Order {
02 private Set items;
03 private String name;
04 private Long id;
06 public Long getId() { return id;}
08 public void setId(Long id) { = id;}
10 public Set getItems() { return items;}
12 public void setItems(Set items) { this.items = items; }
14 public String getName() { return name; }
16 public void setName(String name) { = name; }
17 }


XML is necessary in the Java implementation because it allows you to

change the Order object without having to recompile the Java.

Now let’s look at the equivalent class in Ruby:

01 class Order < ActiveRecord::Base
02 has_many :items
03 end

Note the lack of XML and “scaffolding”. Note the lack of code, for that matter.

Which would you rather code? Which would you rather maintain? Which

method seems like archaic ice boats and saws, and which seems like a


Yes, I’ll keep up with the Visual Studio and Java worlds, and maybe

crank out an app or two using them, but for me — and my fellow

developers here at Tucows — the really interesting programming tools

are elsewhere.

Leave a Reply