Spolsky loses his cool

Today I stumbled across Joel Spolsky's article "The Duct Tape Programmer". Essentially it's a thousand word rant to make this simple point:

A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. Shipping is a feature. A really important feature. Your product must have it.

Of course he's right - however, his post is ten agonising paragraphs wherein he rants about design patterns, extended C++ features such as template classes (wait, they've been around for a while now - can we still call them "extended" features), and multi-threading (!!!), and finally one succinct paragraph in which he makes his point (most of which I have quoted above). Now don't get me wrong - I am by no means criticising his writing style ("people in glass houses..." and all that) - all I'm suggesting is that someone with Joel's reputation may wish to think a little harder before posting this sort of tripe online, lest he tarnish his otherwise good reputation. Let me give an example:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

So Joel Spolsky is seriously suggesting that C++, templates, multiple inheritance and multi-threading are invariably going to "doom your project"? Come on. Multi-threading is critical to the success of many projects - without it, or something similar, a huge portion of applications simply wouldn't exist, or at least would be a lot more complicated. I challenge Joel to write a print spooler as part of an interactive application in a single thread. I challenge Joel to write a tool for scientific analysis that must process lots (gigabytes? exabytes?) of data while maintaining an interactive user interface.

As I mentioned earlier, Joel has a point - however, instead of suggesting that any slightly-complicated technology be banned outright, I'll instead suggest that any slightly complicated technology had better be understood by your programmers before you use it in your project. Don't use multi-threading because it sounds cool, use it because it's the right tool for the job.

A New job

It's been a while since I had the time to post here. In the last few months I've left my old emplyer (Pebble Beach Systems), and joined AB Software Consulting. Why the change? I've always maintained that the best way to keep your skills honed is to keep moving. ABSC requires a completely different skill set to Pebble beach. It feels like the next logical step in my career progression.

It's very easy to stay in a job that isn't giving you what you need. Don't make this mistake! If something isn't right, and you've tried fixing it, it may well be time to move. It's a very hard thing to do, but in my case it's been worth it.

Cheers,

Compiling != Testing

Just a small note, folks, to remind you all that just because your code compiles, it's not guaranteed to work. Writing the code is only 10% of the total effort.

I've neglected this blog for a long time now. Hopefully I'll be back soon, but until then, watch this space!

Distractions

I've been very distracted lately - I haven't written any code outside work hours for several weeks now. What's kept me so busy? mainly it's been my guitar(s). I've just added a new guitar to the growing collection. If you're interested, you can see some pictures here.

Microsoft's unpaid testers

I just discovered this charming little quote in the winows 7 blog:

To date, with the wide usage of the Windows 7 Beta we have received a hundreds [sic] of Connect (the MSDN/Technet enrolled beta customers) bug reports and have fixes in the pipeline for the highest percentage of those reported bugs than in any previous Windows development cycle.

So you're publically advertising the fact that your product was very buggy when you launched the beta test phase, and you're scrambling to fix all the bugs at the last minute? Whatever happened to internal testing? Who will test all the bugs introduced with your bug fixes?


Bah, my dislike of the Microsoft software mill continues! Hooray for uninformed opinion!

Webkit / Konqueror issue raised again

Just thought I'd point out that I'm not the only one who would like Konqueror to use webkit rather than KHTML:

WebKit in Konqueror


...It's a pity the comments are 90% flame, and 10% content.

Product Branding Critical to User Expectations

A recent post on kdevelopers.org caught my attention. In a post tagged "rant" (I love rants), "tstaerk" outlines his situation:

I am in a small team where we provide a Linux Terminal Server (LTS) for a company. It is based on NX. Every employee in this company can use the service, however, we provide it free of charge and out of enthusiasm. That means, we are not paid for setting it up nor for giving phone-support. We sometimes have 70 concurrent users on the server, that may mean we reach 500 users on the whole. The server is running KDE 3.5 as desktop environment. Recently, we evaluated - no, let me keep this understandable - we sat together and discussed the possibility of upgrading to KDE 4.

Everyone including me was against the upgrade. This is especially ashaming for me as I am spending every weekend to develop KDE. So what were the reasons?

KDE4 seems to have suffered a lot from people complaining that it's not an easy upgrade from KDE3, and to a certain extent, the complaint is justified. When KDE4 first arrives on the scene, it was really little more than a tech demo, and certainly not usable by normal users (I use the term "normal" users with all due respect - "normal" in this context means users not in the KDE development scene, and perhaps not as technically literate as the developers). However, the hype surrounding it's release meant that lots of normal users upgraded and were subsequently disappointed. With KDE4.2, we're finally getting to a stage where the KDE 4 series is actually usable as a desktop environment.

However, that's still not answering the original concern: KDE4 is still not a replacement for KDE3. Tstaerk goes on to list some of the shortcomings he sees in KDE4:

If you install a KDE 4 desktop by default, you do not have the possibility to add icons to your desktop by right-clicking onto the desktop. That would mean to us: Take 500 phone calls, explain users why it is no longer possible, explain 500 times why we do a change if it is a change to the worse... You got it, 500 times an ENOTAMUSED.

If you install a KDE 4 desktop by default, you do not have the possibility to move the clock in the panel. For me, the clock is ticking constantly on the left where I do not want it. Our users will be upset seeing another change to the worse. Yes, there is a work-around but it is so complicated that I do not want to tell it 500 times on the phone

If you install a KDE 4 desktop by default, you get a strange icon in the upper right corner. No one could explain to me what it is called, but everybody said it was something about Plasma. Users will click on it and eventually hit "Zoom out". Then, their screen is filled with strange gray squares. Just imagine you have to sit on a phone and answer 500 phone calls (for no money) from users who all tell you something about "squares" not knowing they should call it "activities".

Does he have a point? Perhaps.

In some ways, calling the new product KDE4 implies an easy upgrade path from KDE3, which is misleading, since many aspects of the product have been written from scratch, and behave in a totally different manner. It would have been a better decision, I think to brand KDE4 in such a way that it was obvious that it was a new product, that would not work in the same way. This in turn might have saved a considerable amount of grief when developers found that their snazzy new technologies were being ignored, since users could not use the product like they were used to.

So, the moral of the story?

Be careful how you brand your product, especially when a newer version breaks compatibility with an older version. Is it an upgrade, or a new entity in it's own right?