Just A Summary

Piers Cawley Practices Punditry

Blessed are the toolmakers 2

Posted by Piers Cawley Tue, 05 Dec 2006 17:07:00 GMT

My dad drives a vintage Fraser Nash. I say drives, but that’s only half the battle, a large part of his Nash time is spent fettling it. It’s an old car; bits wear out, break or drop off. And because it’s an old car, you can’t just nip round to Halfords and pic up a replacement; nor can you head down to the breaker’s yard and cannibalize something else. So he has a lathe and a milling machine and a bewildering collection of tools. When he needs a part, he will disappear into the machine shop and, after sufficient swearing and/or bleeding, he will emerge with a newly made part. For dad, it’s all part of the fun of running a vintage car. If he weren’t able to do the work, the Nash would have had to remain a pleasant pipedream.

I don’t know my way around a machine shop, except in the vaguest and most theoretical way. The tools I’ve grown up knowing to use are programming languages, editors, fine manuals and the mental tools a grounding in mathematics brings.

So, when I’m putting a new photography business together, and I realise that a couple of the supporting software tools that I had vaguely assumed ‘should exist’ don’t actually exist, I know that it doesn’t matter. I may not know Cocoa programming yet, but I know programming, so I’m confident that, like dad in his machine shop, I’ll be able to knock something up that does the job.

On reflection, I realised that this is probably a good thing. If I can set up and run the business with a combination of off the shelf software, then it’s trivial for potential competitors to reverse engineer the business and do the same (let’s assume here that the business is a success) and I’m left competing on margin in a service industry. No fun at all.

Being able to make my own tools gives me a competitive edge.

Why aren’t there more tool makers?

Because I’m a programer, I know that if my working environment isn’t habitable, it’s possible to fix it. I carry that approach to working with other capable software – keep typing ‘teh’ when I mean ‘the’? Add a macro, autocorrect rule, snippet or whatever you want to call it to the tool I’m using and wonder if it might be a good idea to implement some kind of central repository for such things so I don’t have to repeat myself with every new tool.

The tools to do this sort of thing are there; they’ve never been more available, and in many cases they’re not hard to use, but surprisingly few people seem to be using them. Why is that? Why do people put up with annoying software when (often) the fix is only a couple of settings away? Why are programmers so rare?

I wish I knew. Or maybe I don’t – as long as people don’t realise how easy it is to fix/make things, I’ve got an edge.

Taking control of your tools

If you let your tools shape you, then you’re going to be awfully uncomfortable. Make a commitment to at least capture your annoyances with the tools you use most frequently. Make a note of the problems and think about what you wish the software would do and blog about it. Here’s a couple of stories based on some of the things I need to be able to do for my business:

Auto Slideshows

As an onsite picture editor, I need to run a ‘smart’ slideshow on a secondary display while I working on images on the primary display. The slideshow should be based on an Aperture album and should automatically pick up any changes in the underlying album.

Auto crediting

As an onsite picture editor, I need my slideshow to display a credit on any images in the slideshow that weren’t taken by me. If the Credit metadata doesn’t match ‘Piers Cawley’ the string “by ” should be added as a ‘watermark’ to the displayed image.

If you’re a programmer yourself, you’ve just given yourself a nice list of projects to be working on when you have the time. If you’re not, then you’ve just written a useful set of requirements. Tag your post ‘lazyweb’ and if you’re lucky someone might know how to do exactly what you want without having to write a line of code, or someone else might agree that it’s something that needs fixing and actually fix it. If neither of those two happen, well, at least you’ve vented your frustration, and that’s not a bad thing either.

Comments

Leave a response

  1. Avatar
    Simon Pride about 9 hours later:

    All kudos for you for the idea of using your own IP for competitive advantage, but consider coverage. You’re only one bloke, and you’re up in the top right hand corner of the UK. By all means develop it and use it, until it’s stonking, but then I suggest you capitalize on the work by selling it so that it can be used by people who don’t compete with you. That step’s a tricky one to police, I grant you.

    Also consider – do you want to tie the idea to Aperture? If you’re going to commercialize it maybe a cross-platform language with the ability to look into Aperture, iPhoto, Photoshop / Bridge metabases etc might be less restrictive.

    just my $0.02.

  2. Avatar
    Piers Cawley about 21 hours later:

    Oh, I’m definitely with you on the idea of turning it into a product if it proves to be successful. The problem with a ‘pure’ service rears its ugly head when retirement time comes around. Unless you’ve turned your business into a product or expanded to the point where your employees can happily buy you out, you’ll have nothing worth selling to fund your retirement. Which means either you have to keep working forever, or you have to be wildly successful and shove a substantial chunk of your income into a pension fund.

    Once you reach the ‘product’ point, who cares if people are competing with you on the service side? Competition means people are buying your product, hopefully in sufficient numbers that you can get out of the service game yourself.

    I’m less concerned in the short term about tying it to a specific platform. If there’s one thing that the Rails experience has taught me, it’s that you do much better extracting your framework (product) from something you use than starting with a hypothesis and working up from there. Aperture and OS X are pretty big levers for for building an integrated system, and who cares what the back end servers are running on? One option, looking down the line is to sell a combination software product and backend service. You get an integrated suite of tools to run on your Macbook and a subscription to a web service that handles print ordering and all that good stuf.

Comments



Just A Summary