Monthly Archives: October 2007

Selecting languages and frameworks for developing web applications and the Blub paradox

Via a post on the Scala list I read about the ‘Blub paradox‘ (which roughly stands for the fact that most programmers tend to stick with the languages they already know and/ or go for middle-of-the-road) for the first time, years after it was written. There are a couple of fantastic quotes in there, like:

“You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.”,

and:

“But if you work for a startup that doesn’t have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.”.

I particularly like the first quote. Most web application framework comparisons I know of sum up things like the number of job listings, downloads, list activity and ‘famous references’. And while Wicket is doing pretty well with at least a couple of these numbers, I believe they are crappy arguments. The only thing in favor of even considering those numbers is that when you evaluate technologies, you’ll typically want to know you’re buying into something that has the kind of support you need (bug fixing being the most important part of that). For the rest… it is entirely possible that 100,000 people are just plain wrong.

So what should a good framework comparison look like then?

First of all, match technology with goals. Maybe you are already using a certain combination technologies, and you experience problems with them. Define what these problems are, and seek technologies that try to address these things. The main reason I ended up using Wicket was the inability model 2 frameworks to scale the development effort. But your goals might very different, ranging from delivering as quick as you can, to addressing scalability concerns of your site, to being able to outsource part of the development.

Secondly, the comparison should not be confined to just one language. Compare Wicket with GWT with Rife with Lift with RoR with Django with Seaside first. The language a framework depends on is important, but look at the complete picture.

Third, look at the quality of the framework. When you read (the better) language comparisons, often a fair amount of attention is given to how expressive and elegant certain choices are. And whether what you would produce with that language would be maintainable and easy to read. Include such considerations in that framework comparison. What can you say about the framework’s conceptual integrity? What would your code look like, and what do you think about the framework’s code? Considering the quality of frameworks is largely ‘art’, and – except for undeniable excellent libraries like Guice and Joda Time – it probably comes down to what your taste is. But try to form an idea on this regardless.

Fourth, just bother with the promising ones. A common complaint of people is that there is too much choice. It’s a known economical principal that too much choice makes people less happy with whatever they chose. But it is also known that competition drives innovation, which of course in the end will produce frameworks that will make your life as a programmer better. A complicating factor here is that in the real world, companies go out of business when they fail. That’s not true for open source software. Which is both good and bad. It is good because a library can work great for you, even if it never got a lot of attention. Pnuts is an example for this: it doesn’t seem to be particularly popular, yet I’ve used it in a couple of projects and I am very happy with it. On the other hand, some software should just go away. While Google will hide the greatest losers for you, unfortunately, bad ideas can stick around for a long time. Don’t include Struts 1 in your comparison: it sucks. While it was a helpful project a few years ago, by now there are many far better alternatives. Accept the fact that Struts is a victim of creative destruction. Struts is not alone either, but you can decide that for yourself.

Fifth and last (at least for this post), there is no substitute for trying stuff out yourself. It is never a waste of time to learn a new language, and in a similar fashion, I thnk spending a few hours with a framework you might consider isn’t wasted either.

Tagged , , , , , , , , , ,

Our NYC office is hiring

We’re looking for people for our Manhattan office. Sorry for being lazy, but I’ll just copy the job description here:

Junior Software Engineer(Java)

Teachscape, Inc. is looking to hire a Junior Software Engineer to work in our downtown New York office. We have a small, very experienced and talented team. We work with cutting edge technology and frameworks to deliver professional development to teachers online. This would be a great opportunity for a junior developer to learn and grow from working closely with best-practice software development and world- class Java developers.

Requirements:
* 0-3 years as a software engineer
* BS in Computer Science, or equivalent experience
* experience with server-side Java programming and related frameworks

Core Responsibilities:
* Participate in the development and maintenance of the company’s software systems
* Participate in the creation and maintenance of specifications and documentation

Additional Requirements and Responsibilities:

* Detail-oriented and thorough
* Excellent communication and interpersonal skills
* Experience with client-side web development is a plus
* Engineer will be exposed to the following technologies, any prior experience is a plus: Java, Spring, Wicket, Hibernate, MySQL, Eclipse IDE, Jetty, J2ME, Adobe Flex, Maven, Subversion, Linux, Apache

We’re hoping to get some reactions. We have an interesting team and some very interesting things to build. Please drop me a line if you’re interested or you know someone who might be!

It’s also on DICE.

Follow

Get every new post delivered to your Inbox.