Yesteryear

I spent a long thinking patch releases were the done thing, but now I realise they just mean you’ve got a broken development process.

Yesteryear we worked like this.

A team of people write some code and then commit it to a code repository. And lets say it then gets deployed to an integration environment, and once everyone is happy with that then they deploy it to a staging environment and on to production. And you tag that release version 0.1.0.

Lets say you then decide to add a feature to that code or fix a bug, so you start writing code on top of version 0.1.0. That’s fine, and you release that code in the same way as above, and you call that version 0.2.0, and then you set off with a plan to build version 0.3.0.

But wait! Someone has spotted a serious problem with version 0.2.0.

So we’ve got a choice to make if we want to fix that problem:-

 v0.1.0 - version last known to have worked.
 v0.2.0 - version in production now.
 v0.3.0 - version on integration environment.

Do we, a) rollback to the last known good version 0.1.0, b) patch the code in the production release, and called it version 0.2.1, or c) put the fix in version 0.3.0 and release that ASAP?

The old me would pick either option a) or b).

Probably a) if it were a serious problem spotted in the minutes after release or b) if it was a problem that could wait a few hours to resolve, but looking back at I realise now these options highlighted serious deficiencies with our development process.

The best option is always c).

Not picking c) meant past projects fell in to one or all of these traps.

Problem #1 - Clean Trunk

We couldn’t release immediately because we had code in our master branch (or trunk) we weren’t confident of putting in to production, so any release was blocked until this was resolved. In other words we merged code in to master that nobody had taken a second look at or that we didn’t have sufficient tests around it to prove it worked.

This is easy to fix. Firstly by writing more tests at various levels (unit, integration etc.). And secondly adopting various development approaches (pairing, peer reviewing etc.) that socialise the code before it’s merged in to trunk. Being militant about what’s merged in to the master branch is important here. Have high standards.

Problem #2 - Dependencies

Sometimes not being able to release was because we had dependencies that needed to be released first.

At the very beginning of a project, say, release v0.1.0, this is often impossible to avoid, especially where new systems are being created, but after that point a dependency you can’t quickly turn off will slow your release process down to the slowest denominator, blocking any changes that need to be made more quickly.

So, it’s not always possible to plan for dependencies not being delivered but having a means to stub things out (feature toggles etc.) is the idea here.

Problem #3 - QA

Having non-automated process *after* the code is merged in to master prevented us from releasing quickly. This is most apparent in the QA process.

Most projects employ a tester. It’s very easy to see this person as a backstop - something that happens after the programming stops and before the code gets released. But this is lazy and another blocker to a seamless release process.

Developers should care enough about the quality of what they are producing to check it works perfectly before they dump it in to the source code management system and in front of users - both by writing integration tests or pairing with someone on the team to walk through the change (ie. HCI, testing the change with different use cases).

Sometimes we found it was hard to test something locally - Eg, you can’t connect to a production database, or emulate a state of some dependent system, or physically connect a test device to the developers virtual machine - and committing the changes to the integration environment was the only reasonable way to test them. But this breaks out clean trunk rule (above), so spending time removing these problems yields an environment where nobody has excuses for not testing something.

Rather than employing an army of testers to plough through the work the team has done at regular intervals, use them to impart their expertise to developers to help them understand context in which the code with be used. Help them understand how to test.

And as for people who like writing code but think it’s some one else’s job to check it for them. Well, try to avoid that.

HEAD

The advantage of the above three principals is that you avoid the hassle of patching, which isn’t so much a hassle in practical terms (although typically around our way is does cause more effort that I’d like), more a bad process smell. We’ve tried to keep to these rules while building m.bbc.co.uk/news.

sudo wget http://www.sqlite.org/sqlite-autoconf-3070400.tar.gz
sudo tar xzvf sqlite-autoconf-3070400.tar.gz
cd sqlite-autoconf-3070400
sudo ./configure
make install
export LD_LIBRARY_PATH=/usr/local/lib

document.evaluate( 'count(//p)', document, null, XPathResult.UNORDERED_NODE_ITERATOR_TYPE, null );

The slides, which explain the motivation behind the project, are available as a PDF, or you can view them on slideshare. The video of our prototype that accompanied the presentation is available on YouTube.

Or imagine you couldn’t mentally measure an interface feature in kilobytes. How would be able to decide on the fastest experience for a person on a slow connection?

Imagine if you never read the data model documentation and had to guess the presence, function, relationship and structure of each object. How would you decide the composition of an interface?

Imagine if you had to create tactile interface without ever touching it. How would you comprehend what gestures didn’t confuse?

Imagine you didn’t spend Sunday evening reading through the W3 specifications and browser vendors nightly READMEs. How would you understand what’s going to happen next?

Design is a manifestation of experience, and the experience is ever more complex.

I wrote this because I’m unaware of it being written anywhere else.

Worst-case coding

Developers are trained to code cautiously. Errors and exceptions are predicted and trapped, databases are read before insertions and updates happen, we check caches before we attempt to purge their items. Our code is littered with conditional constructs to determine whether or not we should to do something.

The problem also extends to business analysts. Functional specifications are full of edge cases, ‘a user can’t do this if they’ve already done such and such.’

Your code probably has a lot of this going on :-

if (thing.exists === false)
	thing.create
else
	thing.update
end

Each execution cycle is pessimistic, assuming the worst will happen (that the thing exists and we will try to create it again rather than update it) and so you are, understandably, trying to prevent that and avoid your boss/colleagues/clients from thinking you are bad at your job (by building things that don’t result in error states).

This approach doesn’t always scale.

In many circumstances the chosen path is overwhelmingly going to be one or the other. Lets call this the happy path, the other paths being edge cases, 1/1000 events that will break your system but hardly ever happen.

Here’s an example of our simple code sample presented as a registration system where a user object is queried with a unique id (Eg, an email address) and then created if it doesn’t exist, otherwise updated.

if (user.exists(uid) === false)
	user.create(uid)
else
	user.update(uid, telephone)
end

How many times a day does somebody attempt to register with the same email address as someone else or bypass your systems security to update a user that doesn’t exist? Both these requirements are essential but may be edge cases in some systems.

In this case we make a minimum of two calls to the user object for every registration/update - a read (exists) and a create or update.

Twice doesn’t sound too bad, and it’s often not of course. But let’s say the user object is talking to a web service in a different data centre, each function (exists, create, update) maps to a HTTP method (GET, PUT, POST) on stateless, RESTful API. Let’s also say your site is popular to the tune of 1000’s of requests a second at certain times of the week.

You’ve just doubled the network traffic and operations on that database because of an edge case.

Happy path

Lets look at this problem again. We are wrapping edge cases around our optimal path. Is there a better way we can solve this? What would our code look like if we assumed the best-case scenario usually happens?

In the following example we pass the error handling down to the deepest application layer and the handle the exceptional case if and when it occurs. It works nicely when you know that one path is far more likely to happen the the other.

// assume something will blow up underneath if bad, Eg. mysql
// duplicate primary key error) and then catch that exception
try
	user.create(uid)
	catch(e)
		user.update(uid, telephone)

The above example is crude but came about from high-transaction survey software that I was helping design and build at work.

We found while load testing we could tear out many cautious calls (mostly reads, naturally) to sub-systems like memcached that would throw graceful exceptions when, for example, we tried to create something that was already there. Likewise our HTTP API would send back 409 code when tried to update something that had gone stale.

It’s a simple trick that had a significant impact on our performance.

It’s interesting to me as a developer because knowingly causing lower level errors/exections is counter-intuative to what we’ve been trained to do.

Summary

• Not foreign, most likely English due to his articles on Capello and foreigners.
• Probably in his 30s, but not past it. (not Sol Campbell, Danny Mills, Keown).
• Current in a Premiership squad. (not Craig Bellamy)
• Happily married. (not Peter Crouch or Frank Lampard)
• An outfield player. (not David James)
• Played for several Premiership clubs (unlikely to be Phil Neville, Owen Hargreaves, Clarke Carlisle, Carragher, Kevin Nolan etc.)
• A long stint a one club under a single manager (4+ seasons?) at at least one of them (not Jason Roberts or other journeymen etc.)
• Possibly past involvement in international football (unlikely to be Matthew Taylor, Kevin Davies)
• Played a match the weekend 2nd - 3rd April (so not Joe Cole, Woodgate, Gerrard, Andy Johnson, Heskey etc)
• Strong farther figure (not Joey Barton!)

I think this leaves three possible candidates - Scott Parker, Danny Murphy, Kevin Phillips.

They’ve all had potential to form ‘lifelong friendships’ with an unnamed Scandinavian - Phillips (Sørensen), Scott Parker (Claus Jensen), Danny Murphy (Hyypiä or Riisee). They’ve all played under good and bad managers, most squads have had a small French contingent in the last decade, and gambling seems rife across the industry so that doesn’t give me any specific clues.

Many people think Kevin Davies, but hasn’t played at enough clubs for my liking, so I’m striking off my list - the secret footballer has regularly been involved in transfer negotiations whereas Kevin seems content at Bolton.

I can’t narrow it down further with any certainty.

Murphy is the front runner because of his past media work but that might be too obvious and his 29th January column railed against pundits (he occasionally works for ITV).

A couple of tweets make me think it is Murphy though.

• “Which 3 will be relegated from the Prem this season? My friend is adament Villa will go but they don’t see the type!” - I wouldn’t expect this from a player in the middle of a relegation battle, as Parker is at West Ham.
• “Congratulations to Birmingham. What do you think the difference was? Except one goal…” - Referring to Birmingham in this way would be odd for Phillips.

For my own sanity I’m assuming he’s not given out any false information and that it is a single person, not a group of player, nor a Guardian hack as some have suggested.

So, I think it’s Danny Murphy for now.

Weekly Notes

9 April

• I once won a free-kick playing at Old Trafford and a Manchester United player brought the ball over to the spot where it was to be taken from and handed it to the referee. [I take this to mean he's not played for Manchester United. also definitely an outfield player]
• In a nutshell, that is the “justification” for shouting in the referee’s face, waving your finger at him, lambasting him every time he gives something against you and jogging past him and “getting in his ear”. I don’t overly like it and I’m uncomfortable doing it. [Only an outfield player would have regular opportunity to berate a referee]
• My wife told me that last week … [Currently married]
• I still grew up to be a footballer and, may I say, a fairly well-adjusted one, and that is because of my upbringing and the values that were instilled in me. [strong father figure]

2 April

• I have made some lifelong friends, like the Scandinavian I’ve known for so long that I forgot he wasn’t English. [Long-term EPL Scandinavians]
• A group of French players I played with at one club who were not interested in communicating with anybody else. [Could be French speaking, so covers much of North/West Africa]
• And there was a striker who refused to move unless the pass went exactly where he wanted. [Could be one of many primma donna forwards - Berbatov, Anelka]

19 March

Played at a club with a culture of gambling.

• I’ve known one player who operates on what I would describe as very close to a professional level when it comes to gambling.
• And then there is the complete opposite type of gambler. I’ve actually roomed with one of these and it isn’t pleasant … taking calls from bookmakers all over the world at all hours of the day.

12 March

• I saw a talented young kid reduced to tears in the changing room … thinking back, I can definitely guess [Several references throughout various columns to the younger generation.]
• It isn’t because we’re a superior breed – even I wouldn’t take on that argument with half the England team conspiring against me. [this isn't a very well worded sentence, I'm not sure if we can conclude he's an ex-international]

5 March

This article hints that he’s got an agent with a good reputation.

• When I hang up my boots, I will have opportunity to move on to things I have always wanted to do before I undergo the hip and knee replacements my doctor promised a few years ago. [Obviously an older player]
• I have been in contract negotiations where the Bosman ruling hung over proceedings. [Has been around a few clubs with several contracts]

26 February

Nothing specific in this column but the examples he gives examples of laws he thinks FIFA should introduce, “the situation that arises when a defender shepherds the ball out of play for a goal-kick, preventing his opponent from getting the ball despite making no attempt to play it”, which makes me think it can’t be a defensive player.

Also, this :-

• A friend of mine recently told me his team lacked any clear direction or ambition and, as a result, problems came about which had not been addressed. He said things got so bad that a group of players even began to raise the possibility that it could be a deliberate ploy by the manager to get himself sacked. [99% sure this is a friend of Liverpool]

19 February

• I’ve played for great managers, and I’ve also played for one or two where I would happily have faked my own death if it meant not working with them a minute longer. [Well travelled]
• At one club I played for, it was because of a shared belief that our tactics were flawed, that this was making us look like poor players and, in turn, lose matches. [RE: managers loosing the dressing room]
• I remember at one club being fined for going out to a pub with a couple of friends while injured.
• He was referring to whether or not I escorted a young lady home, despite the fact that he knew I had a long-term girlfriend … I was young back then.
• The first time this happened I had been playing for the manager in question for a long time [had a long stint at least one club] … a man who I looked up to as a god of the game from the way he handled the players, the fans and the media. [But it's not Harry Redknapp] … and it showed him up as a man who, at the time, was troubled. [Houlier?]

I’m reading quite a lot of CVs at the moment. Here’s what I think is important.

Keep it to about two pages when printed. I can’t stress enough the improbability of an unfocussed eleven pager making it past the initial CV filtering process. I do actually print CVs out and scribble on them rather than reading off the screen.

Unless you are a very recent graduate it’s not overly important to me if you got a B+ in your Geography GSCE in 1992. Tell me (briefly) if you got ten straight A’s or were awarded a scholarship, but please don’t list every exam result you’ve ever had.

List your jobs in reverse chronological order. It’s weird how some CVs start with what they were doing in 1995. Fine if you invented the cure for the common cold and won the 1995 Nobel Prize in Medicine. Not fine for less significant events.

I’m no good at spelling, and worse at grammar, so I don’t care overly if the CV has the odd hard to parse sentence, but make an effort. Spellcheck it at least.

Include a URL to some code you wrote. You are applying for a programming job.

Writing this is pretty meaningless :-

• PHP – 7 years
• Ruby on Rails – 4 years
• JavaScript (JQuery, Prototype) - 6 years
• CSS & HTML – 7 years
• XML – 7 years
• XSLT - 4 years
• ActionScript – 8 years
• SEO – 4 years
• …

Am I to think that you have over 92 man-years of experience in your short career or that you’ve stuck a lot of buzzwords in your CV to fish for work? Separate out what you think you really are good at, probably things you’ve been doing on a daily basis for few years. Then mention the few other relevant things you’ve got decent exposure to. The clue as to what to leave in/out will be in the job ad.

On that note, doing this is even worse (taken from an otherwise great CV) :-

PHP OOP, Zend Framework, MVC, Drupal, XML, XSD, XSL, DOM, Xpath, Smarty, Pear, XMLRPC, SOAP, Lucene, Sphinx, SOLR, Cassandra, Thrift, MySQL (foreign keys, optimisation, indexing), ORM (Active Record), Properl, Doctrine, Caching, Memcache, OAuth, Apache auth (basic, digest) EC2, S3, MongoDB, TDD, RAD, Agile, PHPUnit, Xdebug, LAMP, Apache (Linux config, mod_rewrite, system admin, testing, stats - Munin), Tomcat, SVN, Git, Eclipse, Aptana, JEE, Spring Framework, MVC, Hibernate, Tomcat, JUnit, Quartz, Velocity, SOAP, Maven, Ant, Netbeans, Eclipse, Query, Prototype, Ajax, Comet, Mootools, DOM, Behaviour scripting, HTML 5 (canvas), CSS, Mail (SMTP, IMAP, POP3), DNS, DHCP, SSH, Telnet, FTP, Database Server (Sybase, MySQL, PostgreSQL, LiteSQL), Apache, TOMCAT, PHP Server, Ruby on Rails configuration, Memacached, SVN Server …

It’s recruitment spam. Don’t do it.

Also, don’t cut bits and pieces out of the job description and insert them in your personal statement. I’ll spot it.

A four page CV mentioned the word PHP no less than twenty-nine times.

Some people think I need every technical acronym expanding. RDBMS becomes, “relational database management system (RDBMS)”. It’s not necessary.

Irrelevant stuff. Bartender, ice-cream van driver, gardener, please don’t mention jobs that aren’t related to the one advertised. Some people put the fact they have a clean driving license on their CV. The job doesn’t involved driving, or cars.

I don’t really read the personal interests section. I think I might be sociopathic.

The 50-or-so-page book is largely a review of the key events and scientific, cultural and technical achievements falling with in the monarchs reign, which, with hindsight, was only to last a further 7 months (he died in early 1936 from assorted smoking related diseases).

The early 1920s saw attempts to popularise radio broadcasting so included in the book are several references to (upper-class) members of society experiencing the medium.

Here’s my favourites…

1913: A family calibrating their various time pieces using the Parisian 11:30pm broadcast.

1923: Several overdressed folk sat on the London to Liverpool Express were entertained by radio broadcasts from London and Birmingham. The caption reads as if the train carriage was a successful proof of concept rather than an everyday occurrence.

1923: It was noted that a live band in one location could simultaneously play at many private parties. This was later to inspire the work of a Mr Peter Tong of Kent.

1933: Broadcasting House is finished and the 10-year old BBC moves in.

1935: The announcement of a ‘London television station’ was illustrated by an early model of a home tv set (aka. the Baird receiver). Note the comically small screen, I think displaying Adrian Chiles’ face, and some kind of mechanical apparatus built in to the armchair that appears to be associated with the function of the gentleman’s telly (possibly the receiver).