Solutions, better

Welcome to my post-vacation digest:

Extremely useful reading for any internet enterpreneur – Top Ten Mistakes of Shopping Cart Design Revisited, A Survey of 500 Top E-Commerce Websites here.

Ralph Johnson talks about Erlang, the next Java :

Erlang is going to be a very important language. It could be the next Java. Its main problem is that there is no big company behind it. Instead, it is being pushed as an open source project. Its main advantage is that it is perfectly suited for the multi-core, web services future. In fact, it is the ONLY mature, rock-solid language that is suitable for writing highly scalable systems to run on multicore machines. The emphasis was always on reliability, not raw speed, and the system has an incredible reliability history. Joe claims they have achieved “nine 9’s of reliability”.

Being bored by “This site is for iPhone users only” stuff, Eric Meyer sez STOP IT. Stop it right now:

We finally learned, after much sweat and a fair number of tears, that “best viewed in” is a fool’s errand. Are we so eager to rush back into that morass and fight the war all over again?

Since Bloglines released http://i.bloglines.com for the iPhone, this is what I’m using mostly on the desktop (fine for smartphone, too). It’s so much faster than the standard version that it would be a shame to see it blocked. Anyway, I thought all web developers learned the lesson. All we remember holy wars, Netscape failure. It’s all about big boys’ games, nothing good neither for customers nor for developers.

And finally great if not ingenious Slashdot comment on Hiring Programmers and The High Cost of Low Quality I’d like to quote fully:

There’s no one programmer who does the work of ten other programmers. One uber-programmer does just as much work as one ordinary programmer. It’s just that the results solve ten times as many problems. Programming is fundamentally a design problem. A great bridge designer doesn’t do the work of ten lousy bridge designers; the great one designs one great bridge in the time it takes the ten lousy ones to design ten lousy bridges.

The best approximation is that each problem has a certain complexity and a certain size. The size determines how long it will take, and it doesn’t matter how good the developers are. The complexity determines how good a developer is needed to make progress at all. If you’ve got only easy problems, an uber-programmer doesn’t help you much (unless the programmer can find a smaller, harder problem that replaces the big easy one). If you’ve got a hard problem, ten average programmers will work on it forever without getting any results.

And there’s one last thing specific to computers: the computer can solve easy problems for you, but making it do so is a hard problem. But solving that one hard problem (plus some processor time) resolves a lot of easy problems. Another type of hard problem is writing a magic library function that makes a range of moderately hard problems easy enough for average programmers to solve.

If you’ve got ten people essentially doing data entry, an uber-programmer may be able to eliminate the need for them to do that at all. If you’ve got ten developers working on some problem, an uber-programmer may be able to double their productivity. In either of these cases, the uber-programmer directly produces something that isn’t part of the actual project, but the benefit to the project is on the order of ten average programmers’ work. And, if the uber-programmer reduces the complexity of the problem to put it in reach of the rest of the team, no amount of ordinary programmers’ work would benefit the project as much as the uber-programmer’s contribution. Of course, if you require an uber-programmer to literally do the work of average programmers, there’s no benefit at all.