So, you got a bad review?

If you're new here, you may want to subscribe to my RSS feed or you can register for email updates. Thanks for visiting!

Daniel Jalkut in his recent blog discusses a generally positive review of a useful Mac utility that closes with the suggestion that it “should be free.” The crux of his piece seems to be:

In short, if the product were free as in charity, would the product even exist, and be good enough to mention on MacBreak Weekly, where Leo could wish that it was free?

People have different motivations for making good software1 but I think it’s fair to say that the most polished software usually has some form of income stream, whether that’s a licence fee, banner adverts or something less direct.

Of course one problem about selling software is piracy, but fortunately Brad Wardell wrote a great blog entry about just that and the effect that it has on his games company:

It’s irrelevant how many people will play your game (if you’re in the business of selling games that is). It’s only relevant how many people are likely to buy your game.

How, you might ask, is this connected with Jalkut’s argument? Well, the simple truth is that reviewers of your software are not paying customers. Their needs and desires and value judgements are not the same as yours2. Of course reviewers can raise the profile of your program but unless it results in more sales and not just more usage of your software then adding features or lowering the price only to please them is a waste of time.

If you want to sell software, your first priority should be keeping your customers happy, not reviewers.

  1. Jesper notes his reasons for offering his software for free. His argument makes complete sense but does not invalidate Jalkut’s complaint.
  2. I’m reminded of the comparative reviews of word processors that you got before there was little alternative to Microsoft Word. No matter how fully featured the program was, disregarding how user-friendly it was and regardless of the quirky or unique innovations it had, no word processor would ever get an unreserved recommendation without a decent word count feature. How many people even use a word count?

My del.icio.us bookmarks for February 6th through February 11th

My del.icio.us bookmarks for January 4th through January 7th

Blessed is the Tool Maker

In the fifth part of Douglas Adams’ Hitchhiker trilogy, Arthur Dent makes his living among a group of stone-age settlers by utilising the one skill he had that was relevant to that world: sandwich making.

I guess we all have a special skill. But my point in this article is that if you’re a software professional, your special skill (unless you’re stranded on a stone-age planet) should be making software tools.

This realisation dawned on me over a long time. It’s well known that developers range in ability by at least an order of magnitude but less clear why. I’m certainly not qualified to answer that question in its entirety, however I’m convinced that developers can punch well over their weight simply by learning to write software that automates dull tasks, such as writing other programs.

Now a lot of people reading this will be thinking, “What’s the big deal?” Is this not obvious? Does every developer not do this? Originally I thought they did but recently became clear to me that that is not the case.

As is my habit, I had written a small utility program. A colleague was going through the same problem so I shared it with him. Even if we didn’t work for the same company, the script had only taken me a couple of hours to write. I made no claims that it was perfect but I knew that it did most of the heavy lifting required.

Next came the surprise.

A couple days later I conversationally asked how he’d got on with my script. It turns out that it didn’t work straight away; there was a minor bug. As far as I can tell he immediately abandoned my code and spent five hours doing the same thing by hand. He’d not mentioned the bug to me before and, for the record, it took about ten minutes for me to fix the problem that he’d encountered.

So, let’s make things very clear here. This otherwise smart person had done five hours work rather than spend a few minutes looking through a program or, even more bafflingly, ask me a simple question1.

What’s the difference? Why do some people go out of their way to write simple programs while others go out of their way to do repetitive, mind-numbing tasks?

I think it’s simple. Writing a program to write another program just does not occur to many people, they have difficulty thinking in abstract terms and, in general, can’t go “meta.”

Looking back to my university days I remember a number of parallels. A number of people had problems with the assembler course, but the most telling in many ways was on our compilers course. A compiler is a literally a program that writes another program, normally from a high level language such as C++ to assembler or machine code, and to do this you need to keep two separate worlds in your head simultaneously. Firstly you need to consider the program that you’re writing, that is you need to remember all the lexical tokens and the grammar as well as the memory you’re allocating and using. Secondly, you need to keep track of what’s going on in the program that the compiler will be writing when it runs, stuff like the stack, the memory that it will need to allocate at run-time. Since both are just computer programs, many, if not most, of the people on the course had some difficulty getting their head around either the concept or at some level of the implementation.

So far you might think that I’m bragging, but really I’m not. There’s another key part of this. It’s not just a matter of building software tools, it’s knowing when it’s not worth the effort. Had my colleague known that it would take me five hours to fix the problem then he would have made the right move (if we discount the possibility that the script could help other people if fixed).

Similarly, on a number of occasions I have spent far longer building a tool than it would have taken to do it by hand. Sometimes the desire to solve a programming challenge means that I lack the perspective to see when it’s not such a good idea to script the task. Tool building is not without risk. Those truly great developers, no doubt, have both the tool building ability and the ability to recognise when it makes sense to do so.

But overall I still think that one very significant factor in making some developers more productive than others is their ability to write software tools, particularly programs that write other programs.

  1. There’s an argument that the problem here is his communication skills. I’m not convinced that is the case in this circumstance. He’s normally fine. And I think I’m fairly approachable!

Photopress/Lightbox Patch

Ever since I moved over to using the Wordpress content management system to host this website I have been using a relatively small number of plugins. One of my most used is Photopress which you can see in use almost everywhere you see a picture.

However, late last year I realised how much one, small part of the functionality irritated me. You could either view a full size picture in a page on its own, but I’d never managed to create a template that worked well for both portrait and landscape images. Or you could have each image pop up in another window. I wasn’t keen on that either.

I eventually decided to “scratch an itch” and implement option number three. I’d found and liked the “zoom” effect provided by the Lightbox JavaScript library, and so decided to use that.

I did offer the patch to the author of Photopress, but I have heard nothing from him so find my changes here.

You’ll need to follow the following few steps to do the same with your own site:

  1. Disable the Photopress plugin if you already have it installed
  2. Download the Lightbox Javascript library and install it on your webserver. I put it in wp-content/lightbox1. Remember where you put it as you’ll need it again in a couple of steps
  3. Download and install the plugin. If you don’t have Photopress, try this full version. If you already have Photopress 0.9.5, you can download either the only file that’s changed or this patch file
  4. Activate the plugin
  5. Go to the Photopress Options screen. Look at the bottom of the screen. Here you can enable/disable the Lightbox effect and point Photopress to the Lightbox Javascript routines
  6. Also make sure that you have switched off the “Link to Album” feature2
  7. You’re done

Please let me know how you get on. Hope you like it!

  1. You’ll need to keep the same directory structure as in the LightBox ZIP file. For example, you should see three directories “css”, “images”
    and “js” Inside the “lightbox” directory on the webserver.
  2. Thanks to Roman Seibel for figuring this out.

Mirror

This text is taken from the README and explains what mirror does and why I wrote it:

I think that I must have been looking for the wrong thing. When I restructured my web-site it became difficult to upload changes onto the server. What I needed was a program that copied files to the server. While I could find many programs that mirrored a web-site — copied them from the server — I couldn’t find any to do what I wanted.

Being lazy I started to look at other mirror programs with the intention of modifying them. The best candidate, when I tested it, didn’t actually work (no names!) and others had major creeping featurism. All had restrictive licenses.

So I pulled out ‘Programming Perl’ and started coding my own…

It’s not very big or complex, but it does as it says on the box. And as an added bonus it also downloads, just like all the others.

mirror-1.4.tar.gz

If you find another program that does the same job (better), let me know, I’d be interested to learn whether or not I wasted my time!