Archive for January, 2010

Location, Location

January 28, 2010 Leave a comment

 Some notes on a BBC Podcast, Peter Day’s World of Business, transmitted on 22 June 2009 (it should be available in the archive of past episodes).

An interesting episode on how location is becoming an increasingly important tool in how we think about computing.  The programme consisted of a series of short interviews, firstly with the managers of selected companies marketing different geographically aware products, then with a couple of industry commentators to sum up the issues.

The following products (and managers) were featured:

  • Eye-Fi (Jeff Holove), whose digital card for cameras has built-in wifi connection and automatic geotagging of the location the photo was taken.
  • Skyhook (Ted Morgan, Chief Executive), who determine location based on proximity to wifi beacons, rather than GPS which often doesn’t work indoors.
  • Air Semiconductor (Stephen Graham), who have developed a very low-power device that allows mobile devices constantly to keep track of where they are, even when otherwise switched off.
  • Google’s mobile team (Hugo Barra, head of product management), on how they are looking to use location to generate more relevant search results.
  • Onstar (Nick Pudar, VP Business Planning and Business Development), General Motors’ vehicle control system in the USA.

In each case there was a short explanation of what was innovative about the product and the problem it was trying to solve. 

The discussion I found the most interesting was with Graham of Air Semiconductor, as it showed how solving one particular problem can open up unexpected opportunities in other areas.  Using GPS as a location-finding device on laptops is a problem because 90% of the time they are powered up indoors, where GPS signals are often not available.  By leaving the location-tracking device on, even when the laptop is otherwise switched off, it can keep track of where it is.  If the signal is lost it remembers its last known location.  This means that the power usage has to be shrunk so that it doesn’t run the battery down – Graham claims a 100x lower power consumption than anyone else. 

The potential market for this is anything that moves, and not just the obvious mobile devices (laptops, phones etc), but also animals, children or patients who might wander off and get lost.  A further use is for capacity planning purposes – estimating the number of people passing a particular point by counting the number of devices (as they are on).  I’m not sure that it adds much in this respect as presumably this is already possible by counting mobile phones.

There was also a good quote from Hugo Barra of Google.  The discussion covered how location knowledge could be used to better rank search results – and more pertinently, more relevant advertisements.  Discussing the impact of location on advertising, particularly on mobile devices where there is so much less display space available, Barra agreed that they have to make sure that the ad experience on mobile is in no way overwhelming.  Google nirvana is “to give one ad that gives you exactly what you are asking for at that place and time”.

The final section of the programme discussed the possible downsides of your location always being known.  What about privacy?  David Wood of the Symbian Foundation luoted Mark Zuckerman of Facebook, who thinks there’s a kind of Moore’s Law in terms of personal information – every two years we become twice as comfortable about revealing information about ourselves.  At the same time, the industry has to keep customers onside; it can’t go too far or there might be a backlash.  In future it may be that society as a whole finds it easier to have personal information available all the time by default, and individuals may choose to pay to hide some of it. 

Henry Holzman, Chief Knowledge Officer of MIT Media Labs suggested that the future may be less about identifying the location of a device and more about identifying an individual on arriving at a location, e.g. a store may want to recognise me when I enter to draw my attention to certain targeted products.  Mobile technologies are drastically changing the landscape and people aren’t aware of their implications, especially youth who aren’t experienced enough to see the implications of what they post on Facebook etc.  “It will be very very interesting to see how society adapts in 10-20 years to these different sets of norms”.

Categories: Work Tags: ,

Writing user instructions

January 19, 2010 1 comment

An area of software development that is often neglected, especially by in-house development teams, is writing end user documentation.  I don’t necessarily mean a vast manual (which will probably never be read) but simple Help screens or an Installation Guide – anything that will be used primarily by somebody outside the immediate development team.

This is a shame, as we often work valiantly to deliver what our customers want, but then find that when we finally release it, the customer can’t work out how to install it or use it properly because the documentation is incorrect, or incomplete.   Shoddy documents also give an unprofessional impression.

It is extremely difficult to do this well, not helped by disincentives to get on with it.

Deferral.  Even when sufficient resources are allowed by the project plan (and given the all too frequent poverty of planning in many projects, this is usually one of the first areas to be cut out), it is a job many of us in IT prefer to postpone, for more interesting tasks. 

Ability.  Many of us are not all that good at writing, hence the choice to study Computer Science or Engineering, rather than English or History.  Up to now I have worked with only one colleague with the skill of being able easily to write clear instructions on how to do something.

Lack of detachment.  Because we are so close to our own work, and we understand it so well, we can’t see the deficiencies in what we write.  The human brain has an amazing capacity to interpret words to mean what we think they say, rather than what is actually written.  This is especially true where we know the subject matter well.

So what can we do to make things easier?

In my recent role I was responsible for making sure the Installation Guide is kept in line with each release.  I’m not looking at style (however see six simple guidelines and more detailed advice on how to write for busy, grouchy people) but how to produce accurate content without making the job an ordeal.

Here are some suggestions based on my experience:

Start early. It is much easier to build documentation up incrementally, rather than to wait until the system is nearly finished.  This also stops it from becoming a massive task in its own right that needs a large chunk of time on the project plan, probably when everybody is already working flat out to meet a tight deadline.  Start with a bare bones outline and fill in the details as they are known, and keep refining. 

Record exactly what we do. Step by step – as we do it, however trivial.  An Army Major on a Defence project I worked on a few years ago referring to the users of his system, called this “Monkey see, Monkey do” – I never decided whether he meant the NCOs or Generals!  Screen prints are useful but not essential (especially if the look and feel is still subject to change).

Lots of pairs of eyes. Just getting someone to review the document for readability and factual accuracy is not enough.  It helps to find someone brand new to run through it unaided and see where they struggle. In my current project our test team verify the installation guide each time they build a new release, and even though they share it around they are still too familiar with it to spot everything.  Next it is followed by the client test team, and lastly the production support team carries out a dry run of a release and so we get a third real time review of content before it is finally used.

By doing all three, we gradually refined the documentation as we went along, and it was pretty accurate by the time we went live.


January 7, 2010 1 comment

Quite a few years ago now, I turned up at the airport to find that my flight home was oversubscribed.  Would I mind flying in the jump seat?  Where’s that?  In the cockpit between the pilots?  Of course I didn’t mind!  Apart from fantastic views of the approach to Heathrow (sadly, now indefinitely denied to an ordinary passenger), there is one other memory that stuck. 

Before take-off, as many of us are aware, the flight crew run through their pre-flight checks.  What impressed me was the comprehensive coverage.  When I thought they had finished, the first officer produced a second set of laminated cards and carried on.  There wasn’t just an equipment and instrument check, there were also considerations of current weather conditions, route, and what to do if they had to abort on take off or make an emergency landing (it’s a good job I’m not an anxious flyer).

This is standard in the airline industry, where safety is paramount and where any failure is likely to have fatal consequences.  The idea of using checklists first came about in 1936, when the increasing complexity of aircraft started to exceed the ability of the pilot to remember how to fly them.

More recently, the introduction of checklists for certain clinical procedures has seen massive improvements in performance.  A recent study by the World Health Organisation has shown that the use of simple checklists can reduce the incidence of complications during major surgery by more than a third.

The point is to recognise that, regardless of experience or intent, nobody is perfect and mistakes happen.  Checklists are benefical in two ways.  Firstly they help with memory recall, especially with mundane matters that are easily overlooked in a busy environment.  Secondly, they state the explicit minimum expected steps in complex processes. 

In my current project I have had to perform the not very exciting role of QA and Release Manager.  Each software release entails running through quite a large number of checks to verify that its content is as expected and has completed all expected process steps correctly before it reaches me.  I then have to follow a further set of steps to package up the software and to tie up the paperwork to accompany it.  This is all very boring work, but doing it thoroughly minimises the risk of embarrassment later.

On taking over the role, I inherited a process document setting out what had to be done, but it was at a high level and it referred to information that was scattered around in several places.  After my first couple of releases, I realised that there were a large number of small steps that I might easily overlook, so I wrote down everything I did into a simple list as I went along.  With each succeeding release I gradually refined it so I now don’t have to think too much about what I’m doing.  Every time I do a release I print out my checklist (which is less than two pages) and tick it off as I go.  And because it is simple, and informal, it evolves as I find things to change to tighten up my own process in the light of experience.

In fact I found it so useful that I have a separate checklist just to cover which sections to update in the Release Note.  At first I kept making simple errors by starting from the previous document and missing things that needed to be changed.  Since introducing a separate checklist for this routine task I have almost eliminated careless errors.

Using a checklist makes a big difference to me by allowing me to concentrate on the things that matter, as the small things are taken care of.  I no longer have to remember where things are located, as my checklist tells me.  And, as someone with a scattergun brain, it really helps me to remember what I was doing when I was interrupted. 

There is nothing new about checklists in software development.  Stage review gateways usually have a formal checklist of tasks that must be complete before continuing to the next stage.  Process documents describe steps to be taken but are generally too long-winded to work from directly.  In practice, it is not often that a team distils the formal words down into a set of simple steps, to be followed when actually doing the job.  I hadn’t used checklists before except as part of a formal review for signoff, but it has made it so much easier that I shall do so again.


The Checklist, by Atul Gawande published in the New Yorker of 10 December 2007.  A superb article – a long read but well worth it, even if you’re not a doctor.

Verify your work with checklists, from 37 Signals (29 January 2009). See the comments as well.

Why won’t we use checklists? By John Crossan (27 February 2009).  Aimed more at manufacturing, but makes some valid points.

Categories: Work Tags: ,