Apple Pie

I can't help thinking that the latest spat over Apple iPod's being manufactured with (handy) onboard windows viruses is a great example of a "marketing" lead company not really "getting it".

The first reaction of this company on finding out that it was shipping viruses to it's customers... blame Microsoft; sterling effort Apple, IMO that's a bit like putting a blindfold on and driving into a brick wall, then blaming Ford because their car can't predict your stupidity.

I believe Apple's biggest headache is not viruses or their manufacturing processes but that their market is becoming too smart to believe this kind of intelligence insulting crap anymore as witnessed by the general outcry in the Blogosphere about this. Come on Apple, no one expects perfection (marketing <> realworld) so fess up, take the pie in the face, fix the problem and move on.

Mass Observation

There is a campaign going on here at the moment to get people to contribute a "blog" entry to http://www.historymatters.org.uk; the idea is that as many people as possible describe a "day in the life" for the 17th October and the individual entries will be saved for prosperity at the British Library archive for future generations to paw over. I'm not ashamed to admit I'm a sucker for these kinds of things, I find social history very interesting. In a case of history recording history making, here is my entry,

Went to the doctors today, had a bad back over the weekend and wanted to get some NSAID drugs for the pain. Drove to the surgery and waited for about 30 minutes for the doctor, there was an eastern European family waiting too, listening to them speaking in their native tongue (Polish I think?) made me think about history and change, here we all were sitting in a (real) Tudor house (oak beams etc.) in a small market town in Berkshire traffic thundering by, reading magazines on digital photography and country life while we waited, what would those ruffled Tudor ghosts think of it all. When I returned to my car I discovered I had a puncture (argh!), called the tyre repairers but will have to wait until tomorrow for them to get the right tyre; got home OK but I’m a bit stuck now, decided to work from home today thank goodness for broadband internet; my wife made a nice shepherd’s pie dinner for the kids and I; bed by 11pm.

I think the character limit is 4000 and you need to get your entry in by the end of the month.

GooTube

So, Google buys YouTube for 900 million quid; WTF!

I'd love to know what kind of multiple on earnings that represents; if indeed YouTube actually made any money after paying for their bandwidth bill!

I can only speculate what the strategy behind this move is, clearly there is one and it must be something special for this kind of dosh. I wonder if the idea is to create a kind of "alternative" to television; or like MTV did in the 80s invent a new kind of channel? I often look at YouTube, it can be very amusing, but most of it is puerile teenage stuff and people trying to "make it" in media, but hey there are millions of teenagers out there who probably think this is the greatest thing since sliced bread and would happily contribute and watch it all day long. The prospect of targeting this audience with relevant product plugs would certainly be an advertisers wet dream and then some. I do wonder though, much like MySpace and Rupert Murdoch, would trying to exploit such a community in the old fashioned corporate happy-talk manner somehow destroy it or change it in a kind of Heisenbergian way, i.e. to observe it is to change it, or are Google the only company who can pull this kind of thing off?

I have recently been following an interesting blog by Ben Hammersley http://www.benhammersley.com he is a photographer, blogger and technical author, he comments on all things Blog/WEB2.0; Ben is in the process of writing a new book entitled "The Eight Big Ideas You Need to Understand in the 21st Century", one of the "ideas" is "Mass amateurisation - how everyone can publish their work. DIY capitalism such as car-boot sales", I can see how this prophecy could certainly ring (as in kerching!) true for the boys at YouTube (lucky chaps).

Happy birthday to me!

It was my birthday yesterday, I think that beyond a certain age birthdays are best navigated in stealth mode, although, among other goodies, I did get some much needed underwear (you can't go wrong with pants!).

For a special birthday treat my wife & I went to a local restaurant, l'Ortolan see http://www.lortolan.com , it's certainly the poshest gaff around these parts (one Michelin star) and I've been there 5 or 6 times over a period of at least 10 or so years, the previous time being about a year ago. It's interesting to compare and contrast the experiences I've had over this period as the chef has changed, the food and wine changed and probably more importantly my own expectation and experience has changed.

I found the restaurant was great at first, back in the early nineties food in the UK generally wasn't that great (unless you lived in London) but having a gourmet restaurant out here in the "burbs" was a great novelty, like a taste of a glamorous lifestyle up until then only available in London, Paris, New York etc. Like all novelties I guess it wore off after a while, the popularity grew as did the prices and the value fell; I didn't visit for a few years and when I did I found the VFM to be "average" at best. Our visit last year though suggested that the cycle seemed to be back up again , the meal we had was very good indeed (8.5/10). Our food last night was good also (but not quite as good as last time) a couple of small things could have been improved, and overall I would say that 8.5 of last year dropped to a 7, I wonder if l'Ortolan has peaked?

A couple of factors worked against them last night, namely they just switched from summer to winter menu that morning (so I guess the dishes were new); also the place was pretty quiet (Tuesday night), so the atmosphere wasn't as good as say a Friday or Saturday etc. Also I found the food, although tasty, superbly presented and original simply wasn't hot enough - seems like a strange mistake to make for an establishment like this? My other gripe, although I must admit l'Ortolan isn't too different from most restaurants these days, was the wine list. Most of the classic regions were represented on the list, Bordeaux, Burgundy, Rhone, Italy, Oz, USA, Spain etc. but the choice in each was limited and the mark-ups punishing.

When I first went to this restaurant I knew nothing about wine, like a lot of people I simply picked something "reasonable" with a regional name or grape I recognised, i.e. Chablis or Merlot etc., back then red with meat and white with fish was about as discerning as it got. As I have learnt more about wine my choices and expectations have grown accordingly, I now look for producers I like, in good vintages, with wine characteristics that might complement the food, most people would think this increased insight would be a good thing, however there is a serious down-side to it, I know how much the wine actually costs.

Let me illustrate my point with some examples I noticed from last nights list, Beaucastel 1999, this is a Southern Rhone wine, great with things like duck and venison (strong meats), now, 1999 was an OK vintage not great, and many would say that the 1999 is only just reaching it's drinking window (the period of time when the wine shows it's best character). The price on the list for this wine was £90, I know for a fact this wine can be bought from a wine merchant for roughly £25, even at the cheaper end of the spectrum £10.99 Chilean wines (available in nation-wide merchants like Majestic - so by no means rare) were on the list for £35-40. At the upper end of the scale, some of the "trophy" Bordeaux wines hit mark-ups of 5 or 6 times the price you could expect to pay for the same product directly from a shop or merchant.

So, is this exploitation of the "majority" of clients who know no better or is it a justifiable component of the whole "Michelin star" experience, who knows I have never seen the P&L of a restaurant like this, what I can say though is that I eat at home a lot more these days!

Writing code or writing specs?

The eternal dilemma; anyone who's ever written software faces this dilemma all the time, that is,

Do you write down (on paper) what you (or someone else) are going to do and how it will work or do you just write it (in code)?

There are tons of development methologies, approaches, styles out there in groovy world of software development, but none I have ever read or used is very clear about this important point, to spec or not to spec, that is the question. To be honest I don't subscribe to any formal approach, I tend to use my experience and "gut" to guide me these days, however one thing is for sure, I try not to do too much of either. I find that if I write too much specification then I end up taking too long and get things wrong (aka analysis paralysis), its hard to get the big picture from a 1000 pages of spec. Also if I write down every microscopic detail of how I want something to work then what's left for someone else to do, IMO creativity in software development is an important part of enjoying it. If I don't write enough specification then I end up taking too long often with an experimental mess that's expensive to maintain at the end of it. Detail is needed to explain the why and the how, especially when it's not the designer themselves writing the code.

Well, my latest masterpiece has reached that point (again), the point where I think I have written enough spec. to start writing some code, the approach I take is to write specific and targeted fragments of code (usually the hardest or the least clear parts of the design) This process is always time consuming because its difficult to write something that actually works to the point of being useful, without a lot of supporting stuff around it; so quite often I end up spending more time writing things to create data and meta-data so that I can actually write and test the thing I wanted to in the first place. However expensive though, I find this a critical process; I often *need* to write code in order to establish how I'm going to design something, there is just no other way (without unlimited time that is) Having written code to the point where I am clear in my thinking (this usually involves showing other people!) I will often then revert back to the specification and change and/or complete it.

A trendy word for this process is "prototyping" or iterative development (sometimes called RAD) On the surface it seems like an obvious way to tackle complexity, however a lot of "day-coders" I have known never really "got" the point of the prototype, they mostly thought it was a waste of time, why prototype surely you are clever enough to get the spec right first time? well, no, actually I'm not, neither were they. In my view the point of a prototype is to prove a design feature (either logical or physical), nothing more, nothing less. It is however skill based, i.e. you have to know what you are doing to use it successfully; in my time as a programmer and manager I've seen some hideous products emerge from aimless prototypes or more commonly, chronically disfunctional components that emerge from hopelessly simplistic screen "mock-ups" that were supposed to tell the coders what a system is logically supposed to do. Prototyping and iterative development are things that unfortunately have a bad rep in some quarters, usually because of good old fashioned arrogance (we don't need no stinking prototypes), done right though I believe it's the best approach.

Although powerful, I find this iterative approach requires a lot of discipline; the desire is often strong to simply push on with the code and forget about the spec altogether; this is usually a bad thing in my experience. It's good to write down your design; often it's not until you do this that you see the holes (at least before a coded version is complete, by which time it's too late!), in any case, you should be able to write it down, if you can't then something is wrong. The other good thing about doing things this way is that you actually end up with something that you can show other people; it's often hard to articulate what something will do to either technical or non-technical colleagues, the prototype is a vehicle to do that, but beware, make sure it doesn't become the rod that these same people beat you with when V1 is completed.

My "golden rules" of prototyping

1. A prototype should have some specific "point"; otherwise its just an excuse to cut code too early; a prototype of the *whole* system is pointless

2. Prototype logical or physical things, what or how, don't confuse the two, make sure you know what it is you are testing and that you capture the answer (ideally back in the design documentation)

3. Prototypes are not a substitute for design docs (specs) - unless the prototype is so broad and deep that the spec is not needed (rare, see point one)

4. Prototypes are not excuses for not testing things properly; just because your design held water with 5 transactions doesn't mean it works for 5 million.

5. Sometimes prototyping is harder than just cutting code, clearly if you always get things right first time then you don't need to bother.

6. Make sure the people you show your prototypes to understand what they are looking at and what you expect them to do/say - prototype is not equal to a finished product minus some smoothing of rough edges.

7. Prototypes must have secretive and alluring code-names; dagger, bart, helix, google etc.