Monthly Archives: September 2014


The Importance Of… Process

Early this year, Jesse James Garrett tweeted about process:

This appears to contradict the title of this post, so to give you some more context, I should explain that Adaptive Path is a user experience design and consultancy firm, and show you followups and replies in the twitter conversation that followed:

From a user experience consulting and design perspective, this makes perfect sense – analysing what each particular customer and their users need, and how they interact, will by necessity be different every time. However, it also hints at the inherent complexity that you will sometimes find in web application development. Because from a software development perspective, you need to be Schrödinger about process.

To clarify: at a high level, you need to ruthlessly follow the software development process – gather requirements, design, implement, test, release, repeat. Sometimes, there will be pressure to skip one of the steps. For example, starting implementation without designing first. As I wrote last week, this will cost you. Similarly, in Agile environments, and at a lower level, there is sometimes pressure to change the definition of a Sprint once started. This misses the point of an Agile approach – it is between Sprints that priorities should be changed, and the incremental iterations will produce the desired result. Changing priorities within a Sprint will confuse the team or corrupt work allocation, potentially elongate the Sprint delaying the release, or even produce unreleasable code – it moves you away from “Release Early, Release Often”.

At the same time, you must constantly refine, or change, your process. In Scrum, this is done at the Scrum retrospective, by asking what went well and what could be improved. The theory is to continue doing what went well, and to change or avoid what didn’t. The complexity I mentioned comes into play here. There needs to be context to what you continue to do, and what you stop doing. If implementing a design from a third party didn’t go well, the answer is not necessarily to avoid third party designs altogether – it may be that you need to avoid that particular third party, or that you need to discuss the design requirements with third parties, or any number of possibilities particular to the situation.

Different aspects of product development will necessarily have different processes for achieving their goals. In web application development, requirements gathering of the design, functionality, architecture, and user experience/acessibility/usability of the product could all have different processes. Coordinating the implementation aspects and processes is logistically complex. If the processes which are in place are not followed, it is entirely possible that that coordination will be lost, and your team will end up at a standstill.

Photo by Matthew Burpee via flickr.


The Importance Of… Specs

Have you ever built a house? It’s an analogy often used when developing software. So, have you? Me neither, but one of the things that most people understand about building a house is you need architectural plans. Floor plans in particular will tell you the dimensions of each room, detail fixtures and electrical items, note finishes and construction methods, and so on. It doesn’t just tell you where a door is, but also which direction the door will open in. It means when the construction crew turns up, they don’t need to ask how many bathrooms you want, and where you want to put them. This is all perfectly logical. No one would be accused of stalling when no floor plans are available.

For some reason, this doesn’t translate to software development in quite the same way. Sometimes feature implementations will be requested without more than a description of an idea. Developers will receive it and have hundreds of questions, because an essential consulting and requirements gathering stage has been skipped, and there is no spec for them to implement.

Why does this happen? Mainly because like all analogies, it will break when stretched. Developing software is often not like building a house. Moving a wall is costly – it is easy to understand that because you can see the physical effort involved. In our analogy, moving a wall in software does not afford the spectator quite so clear a view – it can be difficult for someone without a development background to understand why the changes they’re asking for are complicated and expensive to undertake. After all, if repainting the walls is as simple as changing a hexadecimal reference, why should moving the kitchen to the back of the house be any more difficult?

Another problem that seems common is a basic misunderstanding about agile processes. Look up “agile” in a dictionary and you’ll see it described as flexible, nimble, acrobatic. This is what people understand when you say you’re agile, and not so much the idea of iterative development processes. “Well, they’re flexible” they’ll think, “we can always change it later”. And yes, you can tweak things as you go along, but putting the basement in the attic isn’t really a tweak.

Perhaps more importantly, there is a fundamental difference between commissioning your dream house and requesting a change on a software product. The former is often a deeply personal affair, in which the customer is willing to invest their time as well as their money. Getting a customer to invest their time in defining the exact behaviour they want their application to have appears to be much harder – after all they’ve outsourced the work for a reason. I’m told some companies will even reject customers who aren’t willing to invest their time in this way.

Some time ago, Steve Yegge wrote an absolutely brilliant blog post entitled Have you ever legalized marijuana? If you haven’t read it, please read it now. Go ahead, I’ll wait. Done? Good, isn’t it? Steve makes a very strong point in the article – that what seems like a simple idea, which at first glance makes perfect sense, may turn out to be completely insane when it comes to implementation. If customers write a spec they might see this – the process of writing the spec will force them to think about how it might all work, and they might quickly come to the conclusion that it’s not going to work. More often than not, however, the job of analytical thinking will fall to a development team. This tends to make sense, as this is something developers are well equipped to do, and which they are good at.

But what happens when developers have to think about how to move the basement into the attic, or their feedback isn’t given due consideration? Steve mentions something which isn’t necessarily front and centre of the article, but which I’ve found to be true:

Because that kind of shit happened at Amazon pretty much every week I was there, for almost seven years. (And astonishingly, we actually managed to launch at least half those crazy ideas, by burning through people like little tea lights.

You will burn out your developers. Working on insane projects will lead you to insanity. So not only will you have to deal with the logistical nightmare of working without a plan, suffer the delays and extra expenses that that will incur, and strain the relationships with your clients, you will also find yourself having to recruit more often (and consequently spending more time and money on training).

If you take away only one thing, make it this: if you set off without a spec, you will never know whether you’ve delivering what was expected. I know, I know – sometimes it feels like the way to go about a feature is to start coding and see what’s possible (I’ve done this myself). But even in a healthy agile environment, a spec will provide you with a solid platform to start off from. Spend the time to prepare a spec and discuss the issues around it upfront, and save yourself the strife.

Photo by Will Scullin via flickr.

Book covers

Recent Reads

I’ve been having a good run in the books I’ve been reading recently. In fact, the best run I can remember, with some books which I’ve found truly memorable, so I thought I’d share some thoughts here.

The Martian by Andy WeirThe Martian by Andy Weir

The premise of The Martian is pretty straight-forward – astronaut Mark Watney gets stranded on Mars and must devise a way to survive. The book is effectively survival sci-fi, but seems so grounded and researched it reads like a non-fiction thriller. Maybe I lack the background in space exploration to find faults with the technical descriptions, but it all sounds so right. I read it in about two days.

One of the criticisms that has been levelled at the novel is that it is too descriptive in outlining how Watney solves each of the problems he faces. Yet as an engineer, I found it utterly fascinating.

The other bit of criticism that readers have is that there’s not enough depth to the characters. This is perhaps fair, but it’s hard to fault a novel so compelling and well-paced – it just isn’t missed. It spans a long period of time, and has enough wit and geeky references to allow the reader to connect with the character in a different way.

I’m in no way surprised to hear that a film adaptation is already in the works, and I’ve already added Andy Weir to the list of authors I follow closely.

Tigerman coverTigerman by Nick Harkaway

Nick Harkaway’s latest is, without a shadow of a doubt, his best yet. Set on the fictional island of Mancreu, a sergeant of the British Army quietly serves out his time until an explosion of violence changes things.

Like his previous novel Angelmaker, Tigerman is set in what feels like a slightly warped reality. It could be our world if a butterfly had flapped its wings 500 years ago. The island of Mancreu is a character in itself, and I felt it apt the name had a ring of The Island of Doctor Moreau.

Having said that, the novel defies categorisation. Nick Harkaway himself recently asked on Twitter:

Would be really interested to know how you’d categorise Tigerman. Thriller? Mystery? Comedy? Tragedy? Comic book pastiche? (Work question 🙂

It is all of those. But it is also a political satire, a morality tale, a sentimental and emotional story, a net-speak reference guide, and more. The book is packed with ideas.

As “the boy” would say, it is full of win.

Robogenesis coverRobogenesis by Daniel H. Wilson

Robogenesis is the follow up to Robopocalypse. In Robopocalypse humanity fought the machine uprising orchestrated by an escaped artificial intelligence. Look past the cheesy title, and you would have found  a hugely entertaining novel without the overly fantastical themes typical of sci-fi involving AI – it all felt plausible. Bizarrely, some accused the book of lacking scope.

It’s unlikely anyone will accuse Robogenesis of lacking scope. This very much feels like an expansion to the world he’s created, with battling AI’s, independently-thinking robots, and human-machine hybrids. Throughout, Daniel H. Wilson’s background in machine learning and robotics is evident. The increasingly wide nature of life described increases organically enough to feel completely authentic.

Robogenesis is definitely one of my books of the year. It is a shining example of how to write a compelling story involving AI. I find it impossible to see how Daniel H. Wilson could improve on Robogenesis, but I’ll be the first in line to read his next offering. Let’s hope Steven Spielberg picks up that Robopocalypse project again…

The Kraken Project coverThe Kraken Project by Douglas Preston

Or The End of my Book Streak. Douglas Preston and Lincoln Child’s books are a bit of a guilty pleasure to me, particularly their collaborative Pendergast series – the plot is sometimes daft, and I often have to suspend disbelief, but they’re enjoyable page turners which require little effort to read.

Not so with Douglas Preston’s latest offering. If Robogenesis is an example of how to write about AI, The Kraken Project is an example of how not to write about it. [SPOILERS AHEAD]

The plot: an experimental NASA AI, Dorothy, devised for independent exploration of Titan, escapes onto the Internet. That base is already a little thin, and I would have been able to deal with it were it not for the daftness that follows. Where Daniel H. Wilson’s AI’s look for data centers to increase their computing power, Dorothy jumps from one machine to another, seemingly as at home on a supercomputer as on a laptop. It uses fuzzy logic to transform it’s inputs into a visual representation (how?! why!?), and we’re “treated” to scenes such as Dorothy the AI literally getting raped on the Internet.

The developer responsible for creating Dorothy, Melissa Shepherd (why yes, of course she’s a genius-level beautiful blonde Amazon geek who loves the outdoors) has found a “trick” to stop the AI going crazy, a completely new computing paradigm, which she hasn’t shared with anyone because she’s aiming to make herself rich with it (yes, really). Douglas Preston saves the best for last and only reveals this trick at the end and it is… sleep. That’s right, in order for AI to work, it must sleep, and this is why we’ve had a couple of scenes where Dorothy is tired and has a nap.

I only finished the book because I’d started it, and out of some sense of loyalty to Douglas Preston. Honestly, the book is terrible. The plot, the characters, the dialogue, just everything is bad. Stay away.

Bug List

The Importance Of… Testing

Given the importance of testing a software product, it is surprising to still find people who consider it a menial task. Despite testing being a defined stage in the software development life cycle, and increasingly sophisticated tools and approaches, some still believe that testing is simply about “checking it works”. Perhaps this is more prevalent in web application development. After all, anyone should be able to use a website, so perhaps these people think that testing is just about using the site and finding things that don’t work.

Of course, this doesn’t paint an accurate picture of what testing can or should involve. A test engineer working on a moderately complex web application can find many ways to spend their time:

  • Unit testing (although it is more common for developers to write their own unit tests, there can be advantages to having a test engineer write them separately)
  • Integration testing
  • Functional testing
  • End-to-end testing
  • Regression testing
  • Load/stress testing
  • Usability testing
  • Browser testing

It is this last item that seems to be the focus in web application development, to the detriment of everything else. All areas of testing require some specialist technical knowledge, so it can be irksome to find browser testing categorised as something anyone can do, particularly when this area can be a world in of itself.

For example, support for multiple browser versions will increase testing time dramatically (particularly when Internet Explorer is involved), and will require a more advanced understanding of the behaviour and support for technologies provided in each of these versions. Similarly, mobile or responsive support (almost certainly a requirement today as mobile use increases) will require an understanding of the particular  idiosyncrasies of each platform, device resolutions, and the design changes across break points.

All of this is required to ensure that the product being released works as intended in every way. A bad release can turn your customers and potential customers against you, or cause financial penalties when SLA’s are not met. Insufficient testing can mean more time is wasted in solving an issue – investigating an issue 2 months after the development is much harder than doing it the same week, as they will have forgotten the detail of the implementation and will need to re-investigate. It will be even harder if the original developer of the feature has left. Skipping the load testing can put you in an awkward position at peaks, while skipping usability testing might mean you find less users when you expected more.

Lack of proper testing will also pit the development team against you – they want a product they can be proud of, and they will realise that skimping on the testing will cause them more headaches and create more unnecessary work for them, even if you don’t – no one wants to stay late at the office to prepare an emergency release for an easily preventable problem.

So please, hire test engineers, and spend the time to test thoroughly.  A good test engineer will be a very valuable asset in multiple aspects of the product’s reliability and behaviour, and they will save you money in the long run.

Photo by Pascal via flickr.

Suspicious package

Personalised Undercover Marketing

Writing about The Raw Shark Texts the other day, I was reminded of a little experiment I tried some time ago which involved the same book. I originally bought the book because the blurb had piqued my interest:


If you are reading this, I’m not around anymore. Take the phone and speed dial 1. Tell the woman who answers that you are Eric Sanderson. The woman is Dr Randle. She’ll understand what has happened and you will be able to see her straight away. Take the car keys and drive the yellow jeep to Dr Randle’s house. If you haven’t found it yet, there’s a map in the envelope – it isn’t too far and it’s not hard to find.

Dr Randle will be able to answer all your questions. It’s very important that you go straight away. Do not pass go. Do not explore. Do not collect two hundred pounds.

The house keys are hanging from a nail on the banister at the bottom of the stairs, don’t forget them.

With regret and also hope,

The First Eric Sanderson

I read the book pretty quickly, and loved it. I thought my brother James and my friend Dave would love it too. So I did what any sane person would do under the circumstances – I created a new Gmail address for The First Eric Sanderson, and sent them both emails, making sure I copied in both their personal and work email addresses. Neither of them drove at the time, and they lived in Barcelona at the time, so I had to tweak the blurb somewhat:

First things first, stay calm.

If you are reading this, I’m not around anymore. Take the phone and call Fnac. Tell the person who answers that you are looking for a book called ‘The Raw Shark Texts’, by Steven Hall. They’ll understand what you need and will be able to help you straight away. Take the train into the centre. If you haven’t found it yet, there’s a link at the end of this e-mail.

Fnac will be able to answer all your questions. It’s very important that you go straight away. Do not pass go. Do not explore. Do not collect two hundred pounds.

The train ticket is in your wallet, don’t forget it.

With regret and also hope,

The First [Their Name]

And then… I left them to it. I called Dave for a chat a week later. About 15 minutes into the call I said “So anything interesting happening? Have you received any weird emails?”. There was a long pause on the other end, and then: “You! It was you, you bastard!”. As it turned out the email had been quite effective – he hadn’t written it off as spam, and he’d been thinking about it. My brother, it turned out, had even gone to Fnac and asked about the book, though unfortunately they hadn’t received it yet (I’d bought the book when it was first published in hardback in the UK, and I guess it hadn’t made it to Spain yet). He did later get hold of it, and read and loved it.

With most my reading done on a Kindle these days, I expect the next time I do something like this it will have to involve some sort of digital crumb trail.

Photo by Ari Moore via flickr.

Cross-functional Lego team

The Importance Of… Cross-Functional Teams

In this series of blog posts I will be exploring what I feel are some of the important aspects of software development management, particularly in relation to web application development.

A cross-functional team is generally defined as a group of people with different expertise working towards a single goal or objective. Within software development, this means a team of people who will collectively hold all the skills required to develop, build, and deliver the product. For example, when developing a web application, you would want the development team to have expertise not just in coding in the programming language of choice, but also in databases, systems, usability, UI/UX/front-end design, front-end development, testing, technical writing, and so forth.

The common single goal and nature of cross-functional teams make the greatest advantages to the approach seem fairly self-explanatory, but difficult to describe. Perhaps Mary and Tom Poppendieck summarised it best in their book Lean Software Development. They described seven types of waste in software development, and cross-functional teams can help in all of them:

  • Partially done work, or work which has not yet been delivered. For example, work which is yet to be tested. Cross-functional teams minimise the effect of this by ensuring no external dependency – continuous testing can take place, and in an Agile environment delivery is made at the end of each iteration ensuring partial work is not left waiting.
  • Extra features, or providing more features than have been requested. This is particularly pertinent when comparing Waterfall and Agile methodologies – in Waterfall this will not be apparent until delivery, whereas with Agile methodologies there will be more opportunity to act. A cross-functional team can help by providing domain experts who can assess when to stop working on a feature.
  • Relearning, or reinventing the wheel. A cross-functional team can share knowledge and prevent the team from working on a problem which has already been solved.
  • Hand-offs. Handing off work to a third party will suffer from two problems: the inevitable documentation, and a potential degradation of knowledge. Within a cross-functional team, less documentation will be required as there will already be prior shared knowledge, and there will similarly be less room for misunderstanding. All this will lead to fewer delays.
  • Delays. As alluded to above, cross-functional teams will reduce delays in communication and external parties, but also those due to, for example, differing priorities.
  • Task switching. Interruptions can be minimised when work can be coordinated within a single team, without external dependencies.
  • Defects. Not just bugs, but misunderstanding the functionality and delivering the wrong thing. A cross-functional team is better suited to defining the functionality, and involvement from all team members means better test coverage.

There is a certain amount of disagreement on whether Scrum should include specialists in defining a cross-functional team, or whether cross-functionality should be achieved by having team members work in areas outside their area of expertise. In practical terms, I’ve found it to be a little bit of both, but either way I think it’s clear that cross-functional teams are important.

Photo by Simon Liu via flickr.

Neon shark

Building A Twitterbot

Back in June 2012, I was watching Esc and Ctrl – a series of videos from Jon Ronson for The Guardian, in which he investigates attempts to control the Internet in some way, shape, or form. Some of the videos dealt with Twitterbots, and they piqued an interest on how the bots could generate responses from real Twitter users. As I had free time at lunch I thought I’d investigate how difficult writing a Twitterbot could be.

As it turns out, writing a Twitterbot is remarkably simple. This is probably testament to Twitter’s API – as far as I could tell, pretty much everything I would want to do as a user was available also via the API, and the rich data provided by Twitter was well suited to an application which would effectively parse it in order to generate a response. Additionally, there were plenty of libraries readily available for use in a variety of programming languages, so the barrier to entry was very low. I decided to write one, but I needed an idea for a bot.

Some 5 years earlier, I had read The Raw Shark Texts by Steven Hall. For those who haven’t read it, a brief synopsis: a man named Eric Sanderson is chased by a conceptual shark called a Ludovician, which feeds on words, language, human memory, and the intrinsic sense of self. Eric tries to throw the shark off his scent by travelling through unspace – forgotten tunnels, and abandoned buildings – and the use of other people’s information, writing, and dictaphone recordings. Eric wraps himself in a chaos of others. (As an aside, if you’re interested in the book, I recommend a physical copy, as it is beautifully styled with typography pictures which might lose something in an ebook format).

This felt like a perfect fit for a Twitterbot – what if the Ludovician was searching for Eric on Twitter? A drop of information in an ocean of data would attract it, and there was scope for creating a bit of a mashup. I set off to write it, using PHP for quick development. First, I created an outline of what the script would do:

  1. Search Twitter for references to “Eric Sanderson”, “ludovician”, “luxophage”, or “cognicharius” – these would be rare enough to be people talking about the book, or an exact name match which might entice people to investigate further
  2. For each of the resulting matches, follow any users which weren’t already being followed, store the geo location (if available), and issue a reply to their tweet
  3. Every couple dozen tweets, average out the the locations collected to provide a position for the shark, and provide the likely location of Eric based on the number of matched tweets per location

The responses that the bot would issue would start off as relatively descriptive text, and I was hoping to provide increasing measures of stylised text, much like the book offers, with some specific quotes. This is difficult on Twitter, as ASCII art is limited by the formatting, and there is little control of this on the Twitter site or clients. For this reason I decided to use a technique which was used to great effect on YouTube – superscript and subscript characters. The full list of responses I prepared was as follows:

  • Pattern recognised, following
  • Reincident pattern, targeting
  • Reincident pattern, circling
  • Reincident pattern, increasing priority
  • Memorising pattern
  • Pattern memorised, attempting to locate
  • Location compromised, reverting to data collection
  • Target acquired, deploying luxophage: ·~~-=<{((©@) [defined in the book as a parasite that prevents humans from thinking clearly]
  • Awaiting luxophage attachment
  • Preparing for second stage

  • ȇ̑̐ͫ͗ͣ͒͐͠͏̭̱͕̟̝̀͘͡y͒ͩ­̵̷̜̞̼̼̱͓̬̂͒̉̌͐ͣ̾ͨ͡ͅȩ̧̛͙̤̪̞͕̰̃̓͋̈ͩ̒͗̓ͥͫͧ O ̵͓̳̗͓͖̉͛̆ͩ͐̈́͐͗̂̄ͅe̘͕̞͖̼̘̞͊̑̆̓ͩ̿̈̀y̵̴̛̻̯̟̯̩͒͐̄ͦ̓̆̓͠­̹̣e

  • t̤̦͚̭̙͉̒ͯ̍͂͌̈́̍̌͂̿͘ẽ̝͉̩ͧͯ͗ͣ͢e­̲͍t͙̠̣̽̀̈́̚’ͤ͆ͭ̓ͣ̓ͬ҉͉̜̟̩̯h̲͕̋ͮ ̦̯ͅ ͮ̌̎ͬ̿͆<͕­̘͈V̑̿͋̽͢V̦̻ͧͥ̽͗̎ͩ͟V̹̲͚̗̺͞V͎̬̦͞V̝̥͕ͧ͞>̡̣̯̠̱̪͈ͩ

  • for̽g͌ö̜̯̟́ť͚̱̗̺t͎̝̬̦͂e­̲̼̼̳͕̦̯̚ͅn͕ͣs̯͉̓o̦̜̿͋̽m̟̃ͧͯ͗ͣͅẽͬ̿͆ͩ̎̂͡’͕̯̑̑t͕h̰i̯̟n͚̗̺g͎̬̦i̲͕̦̯ͅmp̷̜o͙̤̪͛̆ṛ̡̯̑̆ͩt̲͕̳̗̦̯ͮ̌̿ͅͅ

  • ̵<­ca̤̦͚̭̒ͯ̍͂͌̈́̍ͅpͯḯṯ͆a̜̞̼̼̬ͅl̷ͦ͗ ̭̦̯ͮ̎̓ͥ ̭̦̯ͮ̎̎͋ͅ O̭̦̯̎̎͋͡ͅ ̭̦̯ͮ̎̎͋ ̭̦̯ͮ̎̎ͥͅ o̵͓͖̺ͦ͗ͅpen>­̵

  • g̰̰̰͂a̰̰̰̰̰͂͂ḭ̰̰̰̰͂͂͂n̰̰̰̰̰͂͂͂͂ḭ̰̰̰̰͂͂͂͂n̰̰̰̰̰͂͂͂͂͂g̰̰̰̰̰͂͂͂͂͂ O̦̦̦̰̎̎̎ f̰̰̰̰̰̰͂͂͂͂a̰̰̰̰̰̰͂͂͂͂͂s̰̰̰̰̰̰͂͂͂͂͂t̰̰̰̰̰̰͂͂͂͂

  • f͚̭͌̈́̍̌i̿ͩ͘͟r̻̯̟͠s̈́͐͗̂̄t͓̳ͅ ҉͉̜̟t̷̜̞͡h͓̬̃̓͋̈ͩͅi̧̛ͥͫͧn͙̤̪g̼̼̱̉͛̆ͩ͐̈́ͅs͕̟̐ͫ͗ͣ ̙͉̿͘f͕̞͖͐̄ͦi̼̱̓̆̓ͅr͏̭̱͕̟̀͡s̤̪̞͕̰͞t̠̱̪̑͋̽
  • h͙̠̣̽̀̈́’a̞̼̼̱ͣ̑͗ͅṛ̡̯̠ͬḑ̧̛͙̤̱̪ͩ ͏̭̱̀͘͡t̳̗͓͖ͧͥ̽͗ͅo̘͕̞͖̼ͦ̓̆̓ ̓ͬ҉͉̜̟s͚̭͂͌̈́̍ḙ̱͕̟ͤ̿͋̽e̲͕̦̯ͤ̑̐ͫ͗ͅ
  • Â̵͓̄ͅq͕̟ͯ͗ͣṳ̪̞ͫ͗ả͛̆ͩr̞͖̼ḯ͙̠u̞̼ͭ̓ͣm’̠̣ͤ͆ ̿͆w̲ͬ̋ͮǎ̧̧͙̎s͓̬̃ͧͯͅ ͕͞g̵̷͛̆ͩ͡i̘͈̓̆̓g̳̗͛̆ͩͅa͕̟̝͋̈ͩṋ̱ͣ͒͐t̟̯̩ͧͥi̱̪͒̉̌c̯̠̱ͣ̾ͨ
  • ȗ̟̝̐n͕ͤ̍͢r̼̼ͯ̈́a̱͕ͭ̍v̟̝ͬ̌e͕̞͖ͣ͗l̦̯͘͡ͅl̘͕̞̒i̠̣ͬ̌̎n̲͍ͤ͆gͩ­͚̭̂ ͏̀t͙̤͞ḧ̤̦́͐͗o͛̆ͩu͓͒̉̌ͅgͧ̽­̘͈h̠̱̪ͮ̌ț͚͒ͩ ҉͉̜̟d’̡̣̯ř̦̯a̼̱ͯg̭ͯ
  • ˙ǝʃqıssod ʎɐʍ ʎɹǝʌǝ uı uɐıɔıʌopn⅂ ǝɥʇ oʇuı ‘ǝɟıʃ ʎW

The final response was based on a separate “fragment” of the novel, which fans of the novel were more likely to have read, and made reference to the Ludovician and Eric becoming tangled.

I had initially considered the idea of taking the geo coordinates and doing a reverse lookup with Google Maps in order to get a near exact address to use in the response, but given the responses planned, I felt it might come across as a little too creepy/menacing.

@Cognicharius avatar

The only thing left was to create a Twitter account for the bot. @Ludovician was unfortunately already taken, so I decided on @Cognicharius – the name of the family the Ludovician purportedly belongs to. I used an ASCII art creator to generate an image from a shark photo as its avatar. I set it loose on June 14th 2012, just four lunchtimes after starting.

The bot lived for approximately one year – until the 1.0 Twitter API was retired in June 2013 in favour of the 1.1 API. I didn’t upgrade the bot as I felt the experiment had run its course. In its year of life, @Cognicharius had tweeted 738 times, followed 310 Twitter users, and garnered 91 followers (far more than I can claim). It earned several retweets (including some from Steven Hall himself), generated some amusing responses from people as you can see below, and even got someone to create a Google Map tracking the location of the shark.

Screengrab of Twitter conversation with Cognicharius

Screengrab of Twitter conversation with Cognicharius

Screengrab of Twitter conversation with Cognicharius

Screengrab of Twitter conversation with Cognicharius

Maybe the next bot will just have to message all those users about this blog post.

Photo by staxnet via flickr.