Skype allows you to call regular phones via a feature called Skype-out. They also allow you to receive calls via Skype-in. Both of these cost money. Now, however, you can call toll free numbers for free!

Excellent. All conference calls will henceforth be Skyped. Not only because my home phone will no longer be jammed for hours at a time, but also because I don’t have a speaker phone at home, whereas Skype is hands free, both when I have going thru my nice speakers and when I use the headset.

A little while back I mused about the use of FCKeditor as a WYSIWYG front end for wikis. As it turns out others had been thinking about this, and went on to actually make it happen. Markus pointed out that you can check out the results at the WYSIWYG Editor sandbox, and read more about it on the MediaWiki wiki.

Very nice stuff. It’s still experimental, but go give it a shot.

Btw, this is a great example of why blogging works. I posted a short comment on something I was thinking about, interested parties were able to find it, take it into consideration, do real work, and let me know the results. The whole exchange documented for anyone else interested to see. Before the advent of the blog, I may have mentioned the idea to a few people and then probably forgotten about it.

Now this is just a great post. Joel analyses programmer productivity in about as objective a way as I’ve seen, and comes up with more than a few gems:

The fastest students were finishing three or four times faster than the average students and as much as ten times faster than the slowest students. The standard deviation is outrageous.

I don’t think it’s a stretch to believe this data shows 5:1 or 10:1 productivity differences between programmers.

The quality of the work and the amount of time spent are simply uncorrelated.

If the only difference between programmers were productivity, you might think that you could substitute five mediocre programmers for one really good programmer. That obviously doesn’t work. Brooks’ Law, “adding manpower to a late software project makes it later,” is why. A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time. There are added benefits to using the smallest team possible; the man-month really is mythical.

The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.

Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.

The software marketplace, these days, is something of a winner-take-all system. Nobody else is making money on MP3 players other than Apple. Nobody else makes money on spreadsheets and word processors other than Microsoft, and, yes, I know, they did anti-competitive things to get into that position, but that doesn’t change the fact that it’s a winner-take-all system.

You can’t afford to be number two, or to have a “good enough” product. It has to be remarkably good, by which I mean, so good that people remark about it. The lagniappe that you get from the really, really, really talented software developers is your only hope for remarkableness.

So this is why you should hire the best. Always. Make it a priority. That means you should put effort into recruiting and care about interviews. That means you should make your workplace the place the best programmers want to be at. That means if you need to pay more, do it. That also means you should prune, actively get rid of your hiring mistakes.

Check out Carnival Booth: An Algorithm for Defeating the Computer-Assisted Passenger Screening System, via Bruce Schneier’s post on profiling.

Fascinating. The government’s CAPS screening program actually ends up helping determined terrorists. And if we’ve learned anything it’s that the terrorists are determined and clever.

If security matters to you, always, in all cases, enlist a real expert to help you design the system. What you may think is extra security may in fact be extra risk and exposure.

And, btw, if you don’t read Bruce’s blog, you really should. And you if haven’t read his book, Applied Cryptography, you really really should. I mean that, go read it now, even if you don’t think about security too much. It’ll help you design better algorithms, understand statistics better, and just generally make you a better software designer.

Kurt Cagle has some interesting thoughts on RSS/Atom as a replacement for SOAP. He mentions WS vendors will likely poo-poo the idea, so I’m compelled as a reformed former vendor to comment.

I think Kurt makes excellent points. A lot of the Web is syndication oriented, and certainly RSS/Atom will be a better solution than SOAP for those cases. I generally agree that RSS/Atom will gain acceptance and be used in a variety of interesting places faster and wider than SOAP. In fact I just ran into a surprising one that will be unveiled to the public a bit later.

As Kurt says:

If you make the syndication format too complex for people to use (as I believe is the case with SOAP) then they will migrate to simpler formats as they become available.

Agreed.

However, there’s an important difference between SOAP and RSS/Atom that Kurt doesn’t cover. Besides the basic complexity issue associated with SOAP, there’s the issue of being able to process the data being passed around. The issue of encoding. This usually shows up as interop issues between toolkits, as well as in the XML-to-language-specific serialization / deserialization errors. It’s part of what makes WSDL so complex (although to be sure there are plenty of other factors).

With SOAP, you have to get the payload very exactly right. Otherwise your consumer or producer will get very angry and spew bile all over you. The SOAP oriented world has attempted to specify encoding in the description (WSDL) and use it in the protocol (SOAP). The implementation hasn’t been pretty. To this day it’s still difficult to pass around something as simple as an array and be sure the various toolkits can handle it.

RSS and Atom basically punt on this point. They specify the framework for where to put your data and get out of the way. The actual content is a free for all. In Kurt’s example, he declares it “text/xml”, and goes on to put Job Control Language (JCL) in there. Nice.

How is the consumer to know that the contents are JCL, what JCL is, and how to handle it? RSS/Atom don’t really say. There’s the namespace declaration at the top, but that’s about it.

Compare this with WSDL/SOAP. Your WSDL would have to contain the schema for JCL. You’d likely break it up into methods. You’d figure out what the appropriate input/output for each method should be. Then you’d hope each toolkit calling your service produces exactly the XML you’re looking for. If not, you’d get a nasty message telling you some bizarre looking thing could not serialize.

So which is better? Specifying it exactly or making it a free for all?

To be fair, free for all is not a great description of what RSS/Atom lead to. It’s better described as specifying the core information exchange framework and relying on existing/external means for understanding the specifics of the contents. At a base level, any RSS reader could read my feed and display it, if nothing else. No ugly serialization errors.

Now all the enterprise architects, the folks who do serious things with serious systems, the ones who frown and grimace to keep our country running, will tell you that we need law and order. We need specific specifications. We need to know exaclty what is in that payload, and by golly, if you can’t get it right, you’ve got no business talking to business.

So which is it?

For the Web, free for all is better. As smart people have said over and over, successful Web specifications are forgiving of errors. They’re easy and forgiving. SOAP is trending towards neither of those. RSS and Atom will boldly go where SOAP should’ve gone if we’d done it better.

The Abolish XML Namespaces article is finally published at IBM DeveloperWorks. Here’s the abstract:

Experience shows XML namespaces can be a common cause of confusion and a major complicating factor in XML adoption. In this article, the author argues that XML namespaces do not offer a good solution for the problems they aim to solve, and are not needed for the majority of XML use cases in the real world. His recommendation is to deprecate namespaces or significantly curtail their usage. For cases that require namespaces, developers should use best practices and conventions to restrict the syntactical freedoms offered by the specification such that namespaces present a consistent face that’s easier to understand.

To answer frequently asked questions:
- Yes, that is me in a tux
- It’s from my wedding (circa 7 years ago)

Sidebar: The full length version of that picture, featuring myself in a lovely pose next to a tree, received quite a high ranking (somewhere in the 8s I think) on amIHotOrNot.com . Yes, it was posted on a dare. What can I say, I’m not only brilliant, but also a very attractive man.

It seems all my recent posts are complaints, so I’ll come up with some constructive things next.

I strongly dislike them. Here’s why:

I’ve seen more horrendous programming sins committed in the name of patterns than almost any other possible justification. “Optimization” is close, but somehow I’m more forgiving of that – at least the developer is attempting to be concerned with the operation of the application as opposed to the padding of his resume.

There’s nothing inherently wrong with patterns. They are the distillation of experience into easily recognizable chunks that can be applied to common, frequently occurring segments of problems. You can see them everywhere – in mathematics, physics, mechanics, and yes, even in computer science and programming.

They are, however, a second order tool. They are what you use to refine and speed up your development process. They’re not a substitute for actual understanding of fundamental programming and algorithm design principles. Nor do they take precedence over first order principles.

What am I talking about? Let me give you an example. Here’s the real world:

A senior developer, with 2 developers reporting to him, designed and implemented a subsystem. The need arose for what seemed to be a minor modification, and the developer responded with an estimate of two weeks. We were puzzled – the change had every appearance of being simple. I’d have thought less than a day.

So we dug into the implementation. The developer presented the design of the subsystem. He had used EJBs along with the (name withheld to protect the innocent) pattern. The design hung together fairly well. But there was one glaring problem:

The entire subsystem could’ve been implemented with a fraction of the complexity by using a simple servlet connecting to JDBC. If you wanted to be fancy you could’ve used some abstraction of the database. That’s it. Really quite simple.

We gently pressed the developer on his design choices and why he seemingly favored the complex over the simple in almost every instance. He responded with the usual list of suspects: transactions, scalability, maintainability, ease of understanding.

Good list. Here’s the problem: we didn’t need transactions. Scalability doesn’t hold up: look at the highest scaling systems and you’ll see they’re not EJBs. In any case, servlets would’ve scaled just fine for our purposes. Maintainability and ease of understanding are easy to gauge: it’s easier to understand and maintain less lines of code. Less lines of code good, more lines bad.

Then we looked at the actual code. Good Lord. Copy and paste of major pieces into a several files. Justification? Horrible misuse of the poor, innocent factory pattern. Lines of code? Many. Many. Innocent patterns slaughtered everywhere.

We actually spent quite a bit of time with the developer, attempting to reform him. He was a good, smart guy, worth saving. Unfortunately we were unsuccessful, primarily because he sincerely believed he was right – he was using EJBs and patterns. How could the simple, lowly servlet be a better path?

At the end one of our other developers rewrote the entire subsystem in his spare time in far less than two weeks. Lines of code? Something like 1/5th to 1/10th of the original. Faster. Understandable. Simple. The original developer moved on to create many many lines of code for some other company.

Is this really a damnation of patterns or the case of a bad developer? My point is, this guy was not born a bad developer. He was quite smart, and could’ve been useful. There are many of this guy running around. I’ve seen them.

The problem is, he embraced second order techniques, EJBs and patterns, in place of a first order principle, simplicity.

So when you go out there preaching patterns to the masses, remember the real world. And remember boys and girls: Simple is good. Less lines of code good. You don’t need to throw around the latest acronyms and pattern names to be a 10x programmer. Trust me, I know a lot of those guys too, and most of them couldn’t tell you what that fancy pattern name you just dropped means.

Go read Inside LiveJournal’s Backend for an excellent real world study of how to handle very high levels of traffic.

I shaved my head yesterday. People always ask why when I do something like that. Mostly because I’m an idiot, but also because of something Dr. Martin Luther King Jr. said:

The soft-minded man always fears change. He feels security in the status quo, and he has an almost morbid fear of the new. For him, the greatest pain is the pain of a new idea.

I’m fearful that I’m the soft-minded man, so I try to force external, phyiscal change to trigger and clear the way for internal, meaningful change.

Sound Advice and Blueslugs weighing in on tagging in general and for unix file system respectively. You may have seen Pooya’s and my thoughts on this.

Pooya’s onto something here. He talks about tagging powerpoint slides to allow for easy find-and-paste into new presentations. He’s proposing it would be a feature of Powerpoint.

But why not make it more general and have it be a cross application / medium / location capability? You can tag anything if you have a reference to it. del.icio.us , for example, tags URLs. To make it general, all you would need is a URI for whatever you’re trying to tag.

Imagine for a moment we had unique resource identifiers for all of our resources, from mp3s to pictures to individual slides in a powerpoint presentation. Now imagine a little helper app that would let you tag whatever it was you were viewing at the moment. Now put that together with desktop search, ala Google, Yahoo, and Apple. Voila, you can tag and find everything. To finish it up, we’d need the enable applications to understand our URIs and go to them.

Ok, so the URI for anything part is quite a stretch. But keep in mind, we don’t have to get it perfect. For things that live on my desktop, they can be unique just to me. For apps that already provide / deal with ids for things they manipulate, we’d simply adopt those.

It’s a bit far fetched, but keep in mind Longhorn is planning to RSS everything. That means MS will be thinking of a way to refer to things. So URIs (or something close to it) are on the way…

I love this kind of thing. From New Scientist:

Knowing when you have been ripped off is not solely a human skill, biologists have discovered. Monkeys can spot a raw deal when they see one, and if they are not treated fairly they throw a tantrum.

You can gain so much insight into the behaviour of sophisticated people in complex situations by observing the behaviour of monkeys and children.

Google is sending me the most traffic. After that, at about 1/4 the rate of Google, it’s Technorati. Other search engines are way behind. I’m impressed; at least for my topic area, Technorati seems to be a very popular tool.

I had also started doing del.icio.us tags after reading that it was driving more traffic to ParticleTree than Google. Didn’t do anything for me; I think I got one referer over all.

A new player is stumbleupon. Still a small amount of traffic, but steady.

This is strange. I wanted to put together a simple UI for stepping thru large quantities of data. I’d have normally done this via Tcl/Tk which provides a great environment for quick and dirty UIs, and has the added benefit that I’m very familiar with it.

But, as I went to download Tcl/Tk, it occurred to me that I could use AJAX. All I’m looking for is a simple screen that displays each record in turn. I can slap together the HTML page in no time. I can update the contents of the HTML page by simply slapping the values into javascript variables and eval’ing the result on the browser. Nice and easy.

I have to think thru the back-end capabilities a bit; it may get complicated navigating a very large record set controlled via the browser. If it does work out, it’ll be a very nice separation of logic and UI.

But the main surprise for me was, I now consider AJAX simpler than Tcl/Tk for these types of tasks. Given that I complained about AJAX’s learning curve earlier, I’ve had quite a change of heart.

Ross Mayfield, in a post on Estonia, casually mentions:

in Silicon Valley 70% of CEOs are first generation immigrants

That’s a fascinating stat. First generation immigrants are incredible people, but this is fairly outrageous. I wonder what the stat for new businesses in general is.