james mckay dot net

My nephew Aaron (age 9¾) recently started experimenting with Twitter, as I discovered about a week ago when he started following me. He was not the youngest person on Twitter (that honour surely goes to @rockhardawesome son of @codinghorror son of @spolsky) but his experiment seems to have been fairly short lived. His parents decided to enforce Twitter’s terms and conditions (which require you to be thirteen or over to use the service) after a couple of spammers started following him, but his last three tweets seem to suggest that he won’t be missing it:

Hmmm, there are certain people on Twitter that I could name who really, really need to read that…

Comments closed (4) »

Posted at 22:02 on 29 August 2009.
Tagged: Aaron, Twitter

There are some smart companies that regularly tell you how many people there are ahead of you when your phone call is in a queue waiting to be answered. I wish every call centre would do that. In fact, I wish it were a legal requirement.

Unfortunately, they are very much in the minority. Most companies just churn out canned platitudes that “Your call is important to us” every minute or so without giving you the faintest indication whether you’ll be on hold for two minutes or half an hour. Of course your call is important to them. Especially if you have called an 0870 number, when the longer they keep you on hold, the more money they earn. If you knew you were going to be kept waiting for twenty minutes at 7.5 pence a minute, you’d no doubt take your business somewhere more efficient.

Comments closed (2) »

Posted at 08:00 on 27 August 2009.
Tagged: call centres

There seems to be a bit of intellectual snobbery among some non-web developers, who regard web development as a soft skill, something other than software engineering that’s only for programming wusses who can’t make the grade to get into desktop development. It’s an attitude that is typified by this flabbergastingly arrogant post by Michael Braude (hat tip: Jeff Atwood) who has this to say:

But then, that’s just it, isn’t it?  The reason most people want to program for the web is that they’re not smart enough to do anything else.  They don’t understand compilers, concurrency, 3D or class inheritance.  They haven’t got a clue why I’d use an interface or an abstract class.  They don’t understand: virtual methods, pointers, references, garbage collection, finalizers, pass-by-reference vs. pass-by-value, virtual C++ destructors, or the differences between C# structs and classes.  They also know nothing about process.  Waterfall?  Spiral?  Agile?  Forget it.  They’ve never seen a requirements document, they’ve never written a design document, they’ve never drawn a UML diagram, and they haven’t even heard of a sequence diagram.

Well I have news for you, Michael. This is just plain wrong. As web developers, we have to know and understand almost everything you’ve listed above—and more. Practically the only exceptions that he has listed are compilers, pointers and virtual C++ destructors, and even then some of us may need to get to grips with them from time to time. We need to understand class inheritance, interfaces, abstract classes, virtual methods, pass by reference versus pass by value, garbage collection and so on or we’re toast.

In fact, some of the concepts he’s listed above are even more critical to the web than other, supposedly more superior, forms of development. Take concurrency for instance. This is a particularly difficult concept to understand, debug, work with and test, and on desktop applications which only ever run in single user mode, it is very often a non-issue. You can build desktop applications for years without needing to know jack squat about concurrency, but once you start building web applications, which are multi-user by their very nature, it’s only a matter of time before you get bitten by it.

There are other aspects to web development that we need to understand to a much greater extent than desktop application developers. Security is much more important, for instance. It isn’t exactly a non-issue for desktop applications—web browsers, Microsoft Anything, and so on can be potential attack vectors, especially if they allow scripting—but web servers and web applications are low hanging fruit as far as hackers are concerned, and you have to contend with bots actively probing your site, 24/7, for data injection and cross site scripting vulnerabilities.

I could give other examples. We have to understand scalability and caching. We have to understand not only HTML but also the protocols that run the web, such as HTTP, TCP/IP, SMTP, SOAP, and so on. We have to work with several different languages at once—HTML, JavaScript, PHP or C#, SQL, CSS, and XML and its many domain-specific variants.

We need to work in cross-browser environments that very often make test-driven development particularly tricky if not impossible. (How do you unit test CSS positioning, for instance?) We need to understand graphic design, accessibility, and usability. We certainly do need to understand business processes such as agile, waterfall, scrum, and so on. We need to understand UML. Most difficult of all, we need to know how to bridge the gap between the exact literalism of computers and the vagaries of humans and other living beings.

And guess what? Far from being a cuddly toy, JavaScript is a rich, powerful, functional language that, despite its C-style syntax, was originally heavily influenced by Scheme.

To be sure, there are a lot of incompetent web developers out there, and the barrier to entry is ridiculously low, but it is thoroughly incorrect and misleading to say that this is “because you don’t need to know complicated things to be a web developer.” On the contrary, if you’re working on a site of any significant proportions, you need to know some pretty hard stuff. You need to be pretty smart to be a successful web developer.

Comments closed (3) »

Posted at 08:00 on 17 August 2009.
Tagged: web development

Some years ago, I received an e-mail message consisting of the following instruction:

James, please deal with this by COP today.

followed by thirty or so screenfuls of the sender’s correspondence with the other interested parties. Half of this consisted of the typical lengthy disclaimers that corporate e-mail systems add to all outgoing messages by default, of the other half, 90% was of only tangential relevance to what he actually wanted me to do, and even after I had waded through the entire e-mail, I was still unclear as to what exactly he was asking for. On top of that, this was the first time I had ever encountered the cryptic abbreviation “COP” meaning “Close of Play,” so I had no idea what he meant. He had obviously just hurriedly and lazily hit “Forward” in his e-mail client, appended a quick note, and left me to untangle the mess.

Folks, don’t do this. It simply isn’t fair on someone to expect them to spend half an hour wading through thirty screenfuls of noise to filter out your instructions, when you could just as easily spend a couple of minutes including a summary at the top, and trimming out the extraneous, irrelevant waffle if necessary. Unfortunately, this particular individual made a habit of doing this kind of thing, and it annoyed me no end.

Besides, e-mail is not a suitable medium for communicating requirements that need to be dealt with by COP today. Your recipient may not be at their desk, or may have their e-mail client turned off, or may have a hundred other messages that also need to be dealt with by COP today, or the message may have been trapped in their spam filter. If it is time sensitive, a telephone call is more appropriate.

Comments closed (2) »

Posted at 14:35 on 14 August 2009.
Tagged: communication, e-mail