Month: <span>January 2008</span>

A thin moaning whisper, hissing through gaps, sputtering through trees and racing over roof tiles, strumming cables.

Booming and bursting on buildings, howling and roaring onwards. Thuds and thumps peal from fallen bins, clanging gates fire salvos into the night.

The rhythm continues to erratically bang and clunk, knock and pound. A huge throb of air and rain smashing and whirling around, attacking every window with venom.

Tossing and turning, earful of drips, of gaps, of damage.


Seeing as someone asked…

He’s doing fine.

Ohh you want details? Well he got his booster injection yesterday and didn’t put up too much of a struggle, so he’s now all clear, vaccinated, wormed, flea treatment applied, all ready for his week long holiday in a local cattery. The vet gave him a quick check over and pronounced him fit as a fiddle.

Behaviour-wise he’s been much better this past week and we’re almost at 100% success with a simple, firm “No” stopping him from whatever he’s doing. He generally seems much calmer all round, although we still giggle at his mad half hour antics, particularly the cartoon effect squeaking of a cat trying to turn very fast on a laminate floor (in our hall, which is a hard wearing one so he’s not doing any damage).

Thank you to everyone for their suggestions, as first-time cat owners we are reading lots of books, websites and leaflets, but there is nothing like direct advice from the more experienced.

In saying that, he’s quite the laidback kitten most of the time, making our job a lot easier. Even the trip to the vet didn’t throw him, with no yelping or scratching even when he was doing his secret agent impression, clinging to the sides of his carrier as we tipped it upside-down to try and get him out!

To be honest, I’m more worried about calming down Louise whilst we are away than I am at leaving him in a cattery. He’ll take it all in his stride, whilst Louise will be quaffing gin to calm her fears (I’m only kidding… well, sort of… ).

More photos soon, although it’s hard to photograph a black cat during these dark evenings.


Matt Haughey is, amongst bloggers, pretty well known and respected. He recently wrote up his thoughts on weblog applications and, as they mirror some of my thinking, I thought I’d expand on this theme here.

The title of the post, Bottom line, all weblog apps suck in some way, was borne of frustration and outlines a few points which, reading between the lines, boil down to the same kind of thing.

Few web applications are at the point they could be considered a product.

Matt talks specifically about weblog applications, one of which I use to power this site (WordPress). I do a little web design in my spare time (there’s an oxymoron if ever I heard one) and have a similar working pattern as Matt; create template then drop in the code required by the weblog application, then tweak, tweak, tweak. I share his bemusement at the way Movable Type is configured, and I definitely agree with him when he says:

My ideal blog engine company would hire some seasoned blogger and technical writer to be a documentation czar, keeping docs up to date when new versions are launched, produce screencasts for introductory users, and provide complete documentation at a stable URL that applies to every version of the product. If an outside site does a better job of collecting and offering templates, a documentation leader should recognize that and link to them in highly visible places. There doesn’t seem to be anyone internal at these companies fighting for the users to make sure they can keep being informed about how to best use the product.

All of my knowledge of WordPress, Blogger and Movable Type (three of the biggest weblog applications) comes from tinkering about in the code, trial and error, and random Google searches. Sometimes those searches will take me to the website of the application, but more often than not they take me elsewhere to someone who has solved my problem already, or has a good solution that could be adapted to meet my requirements.

The information is a far more important to me than the weblog application, particularly as most of those meet my requirements and, as I’ve mentioned elsewhere on this website, the supporting information becomes the differentiator which will sway me one way or the other.

Let me repeat what I said previously:

Quite simply, products include documentation, support and training, and tell a cohesive story to a potential user. A story that says, yes this product will do X, Y and Z, and if it breaks we’ll do our best to help fix it, and we’ll support you as you learn to use it throughout the lifetime of your relationship with the product (and, therefore, the company).

The really good thing about this situation is that there is an opening here, a wide gaping hole into which a willing technical writer could leap. Most of the weblog applications are open source and would welcome you with open arms. The role Matt outlines is a huge one, but is perfectly within the reach of most technical writers. You know, if I had any spare time I might just try to get involved…


I’m a grown man. Well, as grown as a man can ever be, and I’m figuring that I’ll never really stop being a small child. Not really. I mean look at the evidence; the toys of our childhood remain but are now called gadgets, as children we were never happier than when we were being looked after and now we use man-flu as an excuse to revert to that behaviour, and of course as babies we fixated on one pair of breasts and as adults, well pretty much anyones will do.

And yes, the latter still applies regardless of sexuality. Show me a gay man who doesn’t wonder over a buxom lady and I’ll show you… actually no, let’s leave that one alone for now.

As I was saying, I’m (considered by some) a grown man yet occasionally I find myself forgetting that fact and reverting to embarassingly childlike outbursts.

Let me pause here and ask you to cast your minds back to the original movie version of Charlie and the Chocolate Factory. Got it? Now, picture Veruca Salt in the nut room, singing her little lungs out:

I want a party with roomfuls of laughter
Ten thousand tons of ice cream
And if I don’t get the things I am after
I’m going to scream

I want the works
I want the whole works
Presents and prizes
And sweets and surprises
Of all shapes and sizes

And now

Don’t care how, I want it now
Don’t care how, I want it now

Apologies, that’ll probably now be stuck in your ear for the rest of the day.

Well, to my horror I reenacted a similar scene today.

Except I wasn’t in Willy Wonka’s factory, nor was I in the egg sorting room. I also wasn’t wearing a red dress with a white lace colour (I keep that for weekends).

Instead I was at home, marvelling at the inadequacy of the customer support offered by Pixmania. Having ordered a new camera through them, they were second cheapest but I get some back through Quidco, I’ve been tracking the purchase.

It had cleared every stage in their process up to the delivery point by yesterday afternoon so when I check again just after lunch, and saw that no further progress had been made, I contacted their customer support via email asking what the delay was, and if I could get an update.

The response I got back was “Your order has been validated and is scheduled for delivery shortly.”

Yeah. I already knew that you muppets!!

And after shouting at the computer screen for a while I realised what folly it was and I slowly backed away in horror. What the hell was I doing? Pixmania clearly stated 3-4 working days from order to delivery and I am still well within that time frame, what was I getting so het up about??

With everything on-demand, instant-on, available now, it’s easy to get caught up in the hype and make unrealistic expectations. Sure, the customer support email I got back from Pixmania would’ve been better received if it wasn’t so blatantly auto-generated, but what was I really complaining about?

Ahh yes, information. Or the lack thereof. Funny how that seems to be the root cause for so much tension and anger.

Anyway, I’m calm now. Almost.


If you are working in an Agile environment, and don’t have “single source” in mind when you write then you are slowing yourself down.

Working in an Extreme Programming environment (an Agile methodology that our Development Group follows) brings a unique set of challenges. During the early stages of a release, we spend a couple of days thinking about what we will be building, writing out the requirements as customer-focussed stories and breaking down those stories into discrete, small, chunks of work each of which has an estimated time for completion.

We don’t have a project plan, and as we work in tight iterations with functionality being released on a regular basis, there is always the chance that the scope will change at some point, generally with little warning. The system is built to deal with this so it’s not as bad as it sounds but it does throw up some challenges for the technical writer.

However with a little thought and awareness it’s a very easy system to work within, but does mean we need to push into other areas a little more.

First up you need to get involved when the developers are writing up the stories. Sit in the customer meetings and any planning meetings. Be the user advocate. Ask questions now. Stories are written from the perspective of the customer (with that customer being the person who requested the functionality) and you can (should!) help to craft these properly, making sure each story remains customer and real-world focussed. Every story, regardless of the functionality that will eventually support it, is a high-level requirement and should be stated as such. The actual work might be to make an object persistent, but the story will only say “The customer wants to be able to view previous transactions for each account”.

You should also be present during the break down of the work. At this point, with each story being broken down into small chunks of work for the development team, you can gain a better understanding of the functionality, including any presumptions and dependencies that may be added. Each piece of work should be no longer than a few days, less is better, and you can start to build an idea of the scope of work during these discussions. As yet I’ve not found any direct corrolation between X days of development work to Y days of documentation work.

So, from the stories, you should have a good idea of the high-level functionality that is being produced, and you can create an outline of the documentation that is required. You should also, having sat in on the discussions, understand the requirements of the customer and the reasoning as to why a certain piece of functionality is, or isn’t, being developed.

The chunks of work can help to feed into each section in your outline, and working to the same principles as the development group, you can estimate each section. Even if the figures are never published, it’s a good idea to take a stab at guess-timating the work based on what you know, allowing scope for research and playing with the software. These guess-timates also re-enforce the fact that you will be working on discrete chunks of work at a time, which should help you cope for descoping of functionality by the development team.

The speed of change is what makes Agile development so popular. If Agile development is the speedboat, the more traditional development approaches are most definitely the oil tanker. Slow to get moving, and hard to stop if a change of direction is needed. Understanding how the work breaks down, and writing in a style that helps encourage and support that, you should be writing discrete chunks of information that can be used anywhere.

In other words, you should be writing as if you are in a single source environment, even you don’t have a database or CMS in place, even if all that content is being held in one document. The principles and structure that single source systems promote will allow you to keep pace with development.

Be the speedboat!


Comments closed

When we bought our house we knew it would take some time to modernise. It’s not been kept in the greatest of care, and we are slowly working our way through the required work. The next big job is a new kitchen, which is getting installed in March, and as we had a little money left over (getting a very good deal on the kitchen) we thought we’d see if we could afford updating the bathroom (the mushroom coloured suite has always been a bugbear).

I’ve phoned 4 or 5 different bathroom places, asking each to come out, have a look and a discussion about what is possible. Two of them never showed up, and didn’t phone to say they wouldn’t make it, so they are struck off the list. Two more have yet to call me back to confirm when they are visiting, which left one company who arranged to send a salesman out yesterday.

Lo and behold he turned up!

I just wish he hadn’t.

Maybe we were spoilt by the guy that sold us our new kitchen (as much as ANY salesman can ever spoil you), but this guy was just… I dunno, BAD.

It started out fine, he turned up, was pleasant enough and asked some good questions when I was showing him the bathroom and talking about what we would like. Now, I made it quite clear that I wasn’t sure what we could afford what we really wanted and that we were looking for some help with the pricing and were more than willing to alter our ideas a little. Basically I was trying to get say that we wanted X, when in reality we expected to be getting Y, and letting him ‘manage’ to get us a good deal for Y.

So he seemed to be playing along and suggested we price up the most expensive layout option (new shower unit, moving the sink, boxing in under the window and the WC) first and work from there.

He spent some time measuring up, talked through the usual brochures and choices and then he jotted down some notes on a pad, totalled up and gave us his quote.

It was about £1k over our budget (we were keeping a few hundred back for negotiation). I told him this and he started humming and hawwing, rapping his pen on his notepad, tapping more figures into his calculator, scratching his head, writing more figures down, and eventually said that (ohh it’s a miracle!) he could come quite close to our budget. It was right at the top of the budget we had told him, and I made some general “not sure” noises to see if he would sweeten the deal.

Now, at one point he had asked us to pick floor tiles to which I said that we weren’t going with tiles so to leave that out of the budget, I’d handle that later.

So when his deal sweetener was to throw in a set of floor tiles for only £100… well I said no.

He then spent a further couple of minutes tapping away whilst Louise and I sat quietly, letting him break the silence first. No, he couldn’t get us a better deal, he was cutting this and this, ohh and this. I asked him to remove the shower option, and his reply was “well yeah, but you want to get it done properly”. My response of “but there is a perfectly good shower there already” was, seemingly, ignored.

He again pointed out that this was a great deal, and that his craftsmen were the best.

And to be fair, it was a pretty good deal so I told him that yes, I thought it was a good deal. To which he replied:

“Ohh ok, so when do you want to get things moving?”

Ummmm. Hello? I asked for a quote.

He looked a little befuddled at this point, and I wonder how many other people he has bullied into taking things they don’t want. I was quite firm, saying we had other people still to come in, but if he left the figures with us we’d call him this week. At that, he all but ran out of the door, leaving no figures behind. He will not be getting a call from us.

Why are good tradesmen so hard to find?


“Don’t know what I want, but I know how to get it”
Jeff Patton revisits the basics of Agile development, and one section leapt out at me.

Saying “shippable” to people in the customer role means implies they’d better get the requirements right because that’s the way Agile development works.

Now, I believe Agile people had something else in mind when they said it. I think they mean keep code quality very high. Keep the code supported with unit and acceptance tests. Take steps to validate each and every user story. It tells testers to get involved earlier and more continuously. It tells developers to develop with a higher attention to quality. (Apparently developers would be developing crap otherwise?)

Which is all well and good, but isn’t there something missing? Hello? Product Documentation?? Regardless of his omission (an oversight, I’m sure) If you are involved in a software team using any form of iterative, Agile development then give it a read.

Collison’s Ignorance Spiral
After every release cycle has been complete, we undertake a Retrospective, looking back at what went badly and what went well, with the aim of carrying forward the lessons learned into the next release. I think we are pretty good at it but some of what Chris says is interesting:

I’ve been in a number of lessons learned reviews where the intent of the meeting seems to be catharsis for the team or compliance with the process, rather than learning for the organisation.

Is that such a bad thing? Sometimes the discussion is more important than the outcome, and if the team needs catharsis then surely it’s better to provide an outlet for it? Admittedly I’m taking what Chris wrote and skewing it somewhat, but he makes some good points.

Top 10 Distraction Stoppers
Nice list of useful applications, particularly item 5 “Minimise your Word Processor”. One of the commenters suggested an application called q10 as an alternative to Darkroom for Windows.

I’ve been trying out q10 recently, mainly for the posts on this blog and for an article I’m currently writing, but I’ve slowly been extending it to other things and I have to say it is very effective. It takes a bit of getting used to but if you have problems focussing on your writing, and I mean REALLY focussing, then it might be worth a look.

Project Blogs, Email and Dual Collaboration Channels
Written in response to a separate post, this paragraph leapt out at me:

A larger question is how to efficiently manage processes that, for historic or practical reasons, require collaboration among multiple communities that maintain a mix of potentially incompatible formal and informal communication processes.

It’s something that we repeatedly visit at my place of work, we have a very successful wiki, and we’ve started to ponder if there are other tools out there that might benefit us in other ways.

In my head there is a need for something like Twitter but with the ability to post slightly large amounts of information (not much, say double the character count). That way anyone can post a quick thought for the consumption of others. Very informal but possibly a good way to capture the myriad of ideas that are generated each day?


Comments closed

What of agile documentation?

It seems like such an old argument that surely, SURELY, doesn’t need revisiting? Alas it seems that the world of software engineering still contains those who think that code = product. Thankfully, in my experience, the numbers are thinning as most practitioners of modern software practices are at least educationally aware of the need for product documentation, even if they don’t fully understand the reasons. However, there are still those who are happy to hack away, and then claim they have a product. If you are such a person let me make one thing clear, you are wrong.

Not only are you wrong but as time marches on, you get further and further from being correct, all the while creating further problems for you and your product.

Just over a year ago, in preparation for my new job, I spent sometime reading up on Agile development and in particular I focussed on Extreme Programming (XP). The more I read the more I came to realise that this was an area which was popular with developers, yet had little to no mention of product documentation as a fundamental part of the methodology.

Mention of unit and acceptance testing as fundamental parts of working in XP suggested there was at least an understanding of the importance of solid, well constructed tests to help make to a “better” application (test-driven development) but the more I read, the more I become slightly disconcerted at the lack of consideration given both to the production of product (end user) documentation or of the benefits and skills a technical writer can bring to a development team.

Truth be told, I’ve still to find more than a passing reference in any of the more recent publications and articles I’ve found but I’m happy to be proven wrong. Perhaps I’ve been reading the wrong things, and visiting the wrong websites? Or, more worryingly, perhaps there really isn’t anything out there.

Obviously, as a technical writer, the role of product documentation as part of the product is something that is at the forefront of my mind, and I’m not expecting any software engineer to have to worry about such things beyond understanding that we are a fundamental part of the product offering and hopefully agreeing that there is a level of expectation setting to be undertaken.

That said, I do expect a software engineer to understand that software without any support, be it formal documentation, training, or a dedicated support team, is NOT a product. If we can’t agree that fundamental trait then perhaps that problem requires a solution (thankfully, as I said earlier, I don’t think it’s a huge issue at present).

Quite simply, products include documentation, support and training, and tell a cohesive story to a potential buyer. A story that says, yes this product will do X, Y and Z, and if it breaks we’ll do our best to help fix it, and we’ll support you as you learn to use it throughout the lifetime of your relationship with the product (and, therefore, the company).

Admittedly the lines are blurring, with better UI design there is less need for the end user to head to the documentation for assistance but I’d argue that, conversely, as UI design improves and more people become aware of the basic principles of software applications (we all know cut and paste by now, right?) then the end users will start to stretch the applications in ways that hadn’t been considered and it is at this point that product documentation (information) becomes the key differentiator between products.

Of course it is possible to happily exist as a technical writer in an Agile world, but I think we need our voice to be louder.

So I guess my question is, who is willing to shout?

Note: I am aware of Agile Documentation, but I’ve yet to read it. It seems to be more focussed on a developer writing documentation though? I’ll post a review of the book soon.