I’ve finally figured out a use for Twitter now. Rather than IMing all of the minor snippets of thought I have throughout the day (and often duplicating those messages for multiple recipients), I just post them to Twitter and let the Internet propagate them.

Here’s my twitter page for anyone who is interested.

Both Ted and myself have recently taken an interest in the works of Seth Godin, one of the gurus of marketing in the Internet age. More than likely we were both influenced by the good things said about him on the Stack Overflow Podcast.

Ted recently reviewed Purple Cow, one of Seth’s more famous books. He gave it a fairly negative review. I haven’t read Purple Cow or any of Seth’s other books yet (they’re still on hold at the library), but I have recently added his blog feed to my Google Reader. Based on what I’ve seen, some of Ted’s comments are right on the money:

If I hadn’t been privy to the blogging phenomena, I’d probably have described this book as The Art of War for marketing, a collection of quips and anecdotes.

…

The author builds some pretty big bridges over the chasm between cause and effect with bold and broad statements along the lines of “product X was crazy successful because of tactic Y,” glossing over any possible nuances of the relationship between the two or other possible external market factors.

Even though I agree with Ted on what Seth does, I don’t get the same negative impression about the results. Much like the Sun Tzu work that Ted mentioned, Seth provides illustrative insights into high-level concepts. Ted is looking for details on how to implement those concepts. Both are important to have; Seth set the direction, the things that Ted reads describe how to get there.

The most interesting part is that Seth left a comment on Ted’s review that said pretty much the same thing:

If you don’t like short and provocative riffs, you’ll hate my blog, I promise. Just FYI, I’m told by happy readers that the book has provoked people to start things, fix things, earn a lot and have fun doing it.

Seth wants to inspire people with grand visions, and hopes that inspiration will help people to discover solutions on their own. That’s a noble goal.

Why do computer scientists often confuse Christmas and Halloween?

Because Oct 31 = Dec 25

I’m not going to explain this one. If you don’t get it, you’re not going to find it funny anyway.

Twelve years ago, while I was in computer programming school, I was engaged in a debate with a not-so-knowledgeable person about the value of a career in software development. He claimed that before too long the profession would be obsolete, as computer programs would be writing computer programs, and the humans wouldn’t be necessary. (He was a medical magnet salesman; I think he was trying to convince me that his profession had more merits.)

Thankfully, I didn’t argue the point much. There would have been little point in trying to convince him anyway, but at the time I didn’t really have a strong argument against it. Circa 1996, RAD and expert systems were big buzzwords, and so it seemed at least possible that, given enough time, research, AI, and computing power, programs-to-build-programs could become reality.

A decade and a couple of computing revolutions later, this dream is looking less likely. We now know a lot more about how little we know about software development. We know how complex and chaotic it is, and we know how poorly algorithms are suited to handling those sorts of problems. We know that the best work is done in organizations that emphasize people over process.

That’s not to say that computers, algorithms and AI haven’t made some appreciable advancements in capability over the past few years. Google is the best-known example. The Roomba and it’s big-brothers SWORDS and Predator have finally brought robotic sci-fi closer to reality. There’s real progress being made on the DARPA challenges. Can software-that-writes-software be that far behind?

I’m not going to attach a timeline to that question, but I do have one insight. It came to me when listening to Stack Overflow Podcast 21 (you can read the transcript here). Jeff and Joel were discussing the role of experts in particular fields, how deep their knowledge really goes, and how applicable it is to new development. Jeff said:

…the way that I’ve characterised [software development] in the past, it’s kind of like a number in binary. Right? So you start off with a bit… which is, you know, zero or one. And then as you go from left to right, you flip all those bits, and say you have six bits. By the time you’ve flipped six unique bits, think how many combinations there are of what you’re doing. It was always amazing to me as a developer, it didn’t take very long at all to get completely off the beaten path, to where, like, virtually nobody is doing what you are doing. And it’s not like you’re doing anything weird. It’s just that you made 6 unique decisions that are all independent of each other, and software development is just kind of like that.

6 trivial changes can make 64 different possible outcomes (2 to the power of 6). What Jeff means is that no situation in software development is exactly the same as any other; the number of variables is so large that the number of outcomes is enormous.

Computers today cannot deal with that sort of complexity. They won’t be able to do so in the immediate future either. With increases in algorithm research and raw power, they might be able to do so someday. I don’t know whether or not that will happen in my lifetime.

What I do know is this: software development is probably the most complex domain in existence. That means that, if computer programs someday replace the software developer, it will be one of the last careers to be replaced. Most of the others will have long since fallen to ever-more-capable robots and algorithms. If you want something that’s future-proof, software development is probably as close as you will ever get.

Stack Overflow is a new site that aims to be the Wikipedia of programming questions and topics. It takes the basic concept of a question/answer messageboard on programming topics, adds in voting and wiki-editing, puts a very good user interface on it, and makes it available for free. The result is an excellent site to find solutions to software development problems of all sorts.

Joel Spolsky is one of the founders; he’s written his own post about the launch.

I’ve been in the beta for about a month now, and listening to the podcasts since their inception. I’m really impressed with the quality of the site and how well they’ve achieved their goals. Their aim is a lofty one: be the best site on the entire Internet for finding answers to programming questions. Even at this early stage, I think they’ve already accomplished that; it’s now just a matter of time before Google confirms it.

If you develop software, it’s in your best interest to familiarize yourself with the site and discover its capabilities. As time goes on it could easily become your best resource on the Web for solving tricky problems effectively and efficiently.

By the way, here’s my user page, for your enjoyment.

In Canada (Rogers Wireless):

iPhone: Base price = $199. Cheapest package: 3 years, 250+E&W minutes, 6GB data = $65/month = $2340. Total price = $2539

BlackBerry Bold: $399. Equivalent package: 3 years, 250 minutes = $40/month, 6GB data = $30/month. Total price = $2919. Options like push email are additional. However: you have far more choice with the BBB. For instance, you can buy it outright (no contracts), skip the data and email plans, etc.

Neither of these plans include taxes, fees, or extras like caller ID and voicemail.

Both phones have similar capabilities (the big difference being less screen vs a physical keyboard). And they’re both really expensive.

In other news:

• Google’s Android has been heating up lately. The first phone just got FCC approval, the SDK is nearly done, and there’s a video of a real Android device.
• I got an iPod Touch recently: an iPhone without the Phone. It’s also without the GPS, camera, microphone, and high pricetag. For me this was the good compromise; I do miss the technical features and the data-anywhere aspect, but there’s no way I’m going to pay $2K for a phone that’s as locked down as the iPhone. The Touch gives me a good music & video player, a wireless web & email browser, and the chance to try out some of the apps for less than $300.

In many (most?) organizations, “being a team player” is code for “being nice” — which, in turn, is often code for “not contradicting anyone.” The problem with this is that it leads to groupthink and mediocre (or often just plain wrong) results.

I think that this Slashdotter has it right: (emphasis added by me)

I’ve worked for years in highly effective teams, and with success. I can tell you what made all the difference: The presence of equals to debate issues with, so that we could talk each other through the problems and emerge from the session with the feeling that we had defined better solutions. Perhaps we are all arrogant nuisances, but as long as we understand and respect each other we keep each other in check, and can function as effective team members.

The “respect among equals” also translates to “respect among people above and below you in the hierarchy” when such hierarchies exist:

• Listen to & consider what your boss says, but call him out on it when he’s wrong or hasn’t justified his assertions.
• Listen to & consider the objections of those below your skill and/or station, but correct them when they’re mistaken and clarify the reasoning behind your positions.

You should only be stating agreement when you reach the same conclusions based on the available information. If you don’t think you have enough information to defend a contrary position, it’s better to state that outright rather than agree by default. The lack of agreement, even without the presence of opposition, might be enough to show that the position is potentially unreliable.

Being a helpful member of a team means working to achieve the same goal as the other team members. It does not necessarily mean following the same process.

Update: Fixed the link to Slashdot. Sorry for that.

While in Costa Rica, I had a brief discussion (with a poker website employee) about the likelihood that a computer will eventually be able to beat any human player (at which point it’s pretty much useless to play poker on websites; you can be assured that everyone there will be an unbeatable computer player). That came to mind when I read this:

100 trillion brain cells and most of us can’t reliably multiply a pair of two digit numbers. If computers had invented humans as part of a BI program (biological intelligence), humans would have been tossed aside as barely having achieved perfect game play at Tic-Tac-Toe. What use is 100 trillion brain cells that can’t reliably compute a 15% tip after a heavy lunch? Many computers would like to know.

From Poker Program Battles Humans In Vegas on SlashDot.

Right now I have the $20 Fido plan, which gives me 200 minutes (which I barely use). Add on $11 for voicemail/caller ID (which are must-haves on a mobile phone IMO), the “System Access Fee”, and taxes, and I spend about $41/month on my phone. That’s about as low as it gets without resorting to pay-as-you-go schemes. I currently own my (unlocked) phone and am not on any contract.

If I were to get the iPhone, I’d:

• Pay $40/month more for fewer minutes.
• Pay an extra $4/month for the same voicemail/caller ID package.
• Get 400MB of data usage. That’s probably too much for casual mobile browsing but probably too little to use as a serious mobile alternative ISP (not that the iPhone can function as a mobile modem; that feature isn’t in the hardware).
• Get access to Rogers’/Fido’s wi-fi hotspots (which appear to only be at The Second Cup; it’s not even at the airport).
• Get locked into a 3-year contract.

When I totaled up the purchase price, extra costs, and taxes, I figure that an iPhone would cost me $1977.15 more (over 3 years) then what I’m paying now. The iPhone is definitely a tempting product in itself, but the really high TCO and the restrictions placed on it (software wise) mean that I’m going to turn it down.

Instead, I’m going to wait for Android (should arrive later this year) and hope that something good will come out of that.

Let’s say that you have a class that takes a generic type parameter:

public class Foo<T> {
  public void accept(T someObject) { }
  public void doSomething() { }
}

It’s difficult to doSomething() to a collection of Foo<T>s when you don’t know what T is and/or there’s multiple types used for T. To work around this, you can create a typeless interface:

public interface FooTypeless {
  void doSomething();
}

The declaration of Foo<T> now becomes:

public class Foo<T> : FooTypeless

Now you can have this method:

public void doSomethingOnAllFoos(
  IEnumerable<FooTypeless> foos) {

  foreach( FooTypeless foo in foos ) {
    foo.doSomething();
  }
}

Also, say that you have the following extension method:

public static IEnumerable<T> toEnumerable<T>(this <T> obj ) {
  // Any IEnumerable implementation should work here;
  // but we'll get to that in a bit
  return new T[] { obj };
}

Type inference would let you write this:

Foo aFoo = new Foo();
doSomethingOnAllFoos( aFoo.toEnumerable() );

However, this code does not work; you get a compile error:

cannot convert from ‘System.Collections.Generic.IEnumerable<Foo<string>>’ to ‘System.Collections.Generic.IEnumerable<FooTypeless>’

This occurs even though Foo<string> inherits from FooTypeless. Even though the generic type parameters are compatible, the generic-enabled reference isn’t, at least according to the compiler. (We humans could probably see that IEnumerable is an interface that could safely be converted, but the existing compiler cannot).

Now, you can do this:

IEnumerable<FooTypeless> someFoos
  = new Foo<String>[] { foo };

…but not this:

IEnumerable<Foo<String>> someStringFoos
  = new Foo<String>[] { foo };
IEnumerable<FooTypeless> someFoos
  = someStringFoos;

You may be tempted to try casting to work around this. For example, this works:

IEnumerable<Foo<String>> someStringFoos
  = new Foo<String>[] { foo };
IEnumerable<FooTypeless> someFoos
  = (IEnumerable<FooTypeless>) someStringFoos;

However, this only works if someStringFoos is assigned an array. The following does not work:

IEnumerable<Foo<String>> someStringFoos
  = new List<Foo<String>> { foo };
IEnumerable<FooTypeless> someFoos
  = (IEnumerable<FooTypeless>) someStringFoos;

If you try this, you’ll get an InvalidCastException. Furthermore, this generates the compiler error:

IEnumerable<FooTypeless> someFoos
  = new List<Foo<String>> { foo };

Currently I have no idea why the array works but the List doesn’t; it doesn’t make a lot of sense to me.

I originally discovered this by using type inference with my toEnumerable() extension method. An easy way around these problems is to avoid the type inference completely and explicitly specify the type of IEnumerable you want:

Foo<String> aFoo = new Foo<String>();
doSomethingOnAllFoos( aFoo.toEnumerable<FooTypeless>() );

This works fine, even if toEnumerable() uses a non-array type (such as List) as its IEnumerable implementation. Execution-wise, nothing has changed, but the generic type used in the call can make or break the code.

Stuff like this starts to make Java’s type erasure look not so ugly in comparison.