The Codist - Programmerthink

Too Many Technologies; Not Enough Brains

Posted: 11/10/2008, Perm Link Readers: 4328


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.

Jonathan Locke 11/10/2008 20:14

You can use Seam with Wicket. Why choose?

11/16/2008 12:20

Is that the same yellowpages.com that has been down for several days now?

Greg from Australia 11/16/2008 12:29

I was thinking the other day about the technological singularity that often gets brought up in conversations about the rapidly increasing pace of technological development where supposedly new things get developed in an infinitely short amount of time. Wouldn't there be an upper limit to rate of progress, like if I remember the results of Mythical Man Month correctly and applied them here, then there would come a time when there is a delay that must be accounted for between teaching new generations about current technology and having them understand how to use current technologies to build new technologies. Just food for thought...

Gabe da Silveira 11/16/2008 18:23

A big problem is how hard it is to pick a winner. I was fortunate when I jumped on the Rails bandwagon a few years ago that both the technology and the marketing were good enough to gain a critical mass. Without that extra attention, Ruby wouldn't quite be a candidate for me in my day job.

However Rails really is the exception and not the rule for good technology. Typically the coolest stuff never gets the critical mass necessary to base your career on it. Yes, I know it's possible to have a career in Lisp, Smalltalk, or Haskell, but you have to acknowledge a significant amount of risk that you'll quickly find yourself in unexplored territory. The risk of that is of course lower in Ruby, even lower in Python, lower yet in Perl, and probably non-existent in Java at this point.

Fortunately there are enough early adopters out there to sift through a lot of new stuff and make it possible to pick and choose your areas of exploration. For instance, I'm starting to get really excited about Clojure. Pure functional programming on top of the JVM really hits a sweet spot of big rewards and low risk.

Tim Jones 11/18/2008 11:05

Thanks for your lucid explanation, Andrew! I feel this way a lot. And, interestingly, recently it's been about the whole <a href="http://www.phpframeworks.com/">PHP framework</a> issue, too. Just when I get started trying to learn one, I read about something "cool" that I can do in one of the others and I start questioning my previous choice. This just gets you into a paralysis mode, where you can't do anything, because you think that you might paint yourself into a corner. Certainly, the open-source movement has created a new "marketplace" for better mousetraps, but at some point, we really need to start having some convergence on these things.

Shadowalker 11/24/2008 15:53

Same feelings here: my impression is that dynamic typing is fun and fast, but you pay it backwhen you debug it. Reflection well done can be very productive as well: only size matters. For medium-small I would go dynamic, for big I would go go Java. Another advantage if dynamic languages is that you can crash out a prototype: showing it to a customer really helps to save many mistakes/misunderstandings.