The Codist

Hardly a day goes by when I read of a new programming language, a new framework, a new way to solve an old problem. Yet the pace of invention and evolution is a two-edged sword; innovation is great but it's impossible to keep up with it.

Two quotes from one of my favorite movies Amadeus

My dear young man, don't take it too hard. Your work is ingenious. It's quality work. And there are simply too many notes, that's all. Just cut a few and it will be perfect.

[Mozart trying on wigs] They're all so beautiful. Why don't I have three heads?

The explosion of new technology in programming has been accelerating in the past decade or so, driven primarily by the open source movement and the web. The ease at which things can be developed, posted, discussed and spread in an environment of free ideas and easy communication is really astonishing. My earliest days developing Trapeze needing only the loose-leaf Inside Macintosh, K&R C and a 68000 assembly manual seem barely removed from days of the knights of King Arthur.

What makes the current warp speed difficult is that just knowing what is happening is becoming difficult if not impossible, much less actually evaluating and learning the new technologies and picking those that make sense to you. I've always spent time every morning following the software technology "market". In the old days I read catalogs and magazines and talked with vendors and it wasn't too hard. Today I could spend every hour of every day and still miss a lot.

Anyone who works in a corporate environment knows how tough it is to get the powers that be to switch to or add a new technology. Even being a member of the architecture team at one place it took a week of painful meetings to convince the team that using Ajax (for an app I was developing by myself for inside the company) wasn't the coming of the Anti-Christ. In my last job one champion of Ruby tried to convince the company that it made sense but finally gave up and left, and the project continued in Java (and to this day is still wandering in incomplete-ville). The problem is finding a balance between using something new and refusing to change for any reason; either extreme can be bad.

Even if a company or group is willing to explore and embrace alternate technologies, the issue remains of how can you find, evaluate and master something new before it becomes obsolete or is abandoned in favor of an even newer technology. At that last job it took several months of work to evaluate a new UI framework between 2 choices (basically Seam vs. Wicket). Recently I read of 20 template systems for PHP. When I introduced Ajax at one company in the first year of Ajax I found nearly 200 frameworks already in progress; I can't image how many there are now. How do you evaluate 200 different frameworks?

The real answer is that you can't; unless we suddenly evolve 8 arms and 3 brains it's impossible today to do even a barely adequate job of winnowing the changes in technology to those that make sense. It's no wonder that many programmers and their employers don't even try and just stick the the same stuff they've been doing. Even if their "approved" choices are terrible, unproductive, unreliable and even expensive there is comfort in the familiar, and fear of unruly change. Yet the pace of evolution ultimately is to make things better, depending on how you define "better". The problem is in the evaluation. It takes time, talent and tenacity to derive what is really "better" and what is just different.

I love the story (although I don't know the exact details) of yellowpages.com. The original development was done in whatever passed for a standard process at AT&T (or whatever they were called at the time) and it sucked. Then a small group of folks built a replacement in Ruby-On-Rails in a few months and it rocked. Of course there are many other stories where new technologies sunk companies as well (one I worked for briefly tried to replace a PHP storefront with a Java application and to this day after four years still has nothing to show for it). New is not necessarily better; better is better. It's telling the difference that is the hard thing.

Well, there it is.