Delivery ( and why it matters )

One of the first questions I ask during an interview is "What was the last thing you delivered ?". It's always an interesting question to get in early during the interview as it tells me a lot about a candidate. Firstly it tests whether they understand what is meant by "delivered", it also allows the interview to open up into a discussion of what they delivered, how they delivered it and what they did once they had delivered it.

The reason for this paper came about during my last project for a major telco, who had a project team mix of contractors and a rather well known Agile software company. During a discussion one evening one of the members of the well known Agile software company proudly announced that during a 9 year career they had never worked on a project that had delivered anything into production.

Two points at this stage :-

1. The well known Agile software company left before the end of the project
2. We delivered the project into production, in fact we delivered several iterations into production.

Lets take a minute or two to discuss what delivery means. Delivery really is only one part of the full project life cycle which if we were a Waterfall or RUP based organisation would be something along the lines of :-

1. initialisation
2. analysis
3. design
4. development
5. testing
6. implementation
7. maintenance

Far too many candidates and a lot of IT contractors seem to think that being part of the first 4 is really cool and CV enhancing, the 5th is a drag, but they suppose everyone has to test. However too few seem to want or believe they should be involved in the latter 2, and it's these 2 stages that really make or break a good developer.

Deployment or more commonly known as "getting the bloody thing live", can be one of the most exciting and at the same time frustrating events of any project. To see the thing you have worked hard on for weeks or months, ( even years ) suddenly working in a live environment, processing live user requests and actually delivering actual value to the customer has to be the proudest moment for any developer. However getting to that moment has to start right from the initiation of the project. A good developer will always be thinking about the end game during every decision point in the project, the choice of libraries, application servers, configuration options all eventually affect how easy or hard it is to deploy an application.

A developer who decides to invent his own configuration file dialect based on a reverse polish notation containing 37 angled brackets per line has probably never had a deployment engineer screaming at him, at 3:00 in the morning, about how to switch off the default debug logging setting which is now generating 37GB log files per minute. That same developer who decides to use one XML library for one part of the project and then use another XML library later on in the project because yet another open source library has been produced and he's desperate to get it on his CV has probably never had a configuration manager hunting him down in the early hours because once again the build fails for no apparent reason.

Deployment should be seen as a design end point, it should also be included in the non functional requirements, which often it isn't. It should scream out at the whole team DEPLOYMENT SHOULD BE AS EASY AS POSSIBLE, because as sure as Lisp wears out the '9' and '0' keys on your keyboard you are going to be deploying more than once. Believe me, you are going to be deploying more times that you ever think you will.

So once you have got it live, the people who pay your wages quite often expect it to stay live, and often to increase in functionality. While some would say this is quite unreasonable, unfortunately it's part of modern day software development and therefore we had all better get used it as soon as possible. This stage of the game is known in the trade as Maintenance. None of us are perfect, bugs creep in, external systems act in ways you never thought possible. Customers try and do something you never thought they would, or some one in Marketing suddenly decides that adding Widget X is the greatest idea they have ever had, and if only you had thought about it before it was released they could have ordered their new DB7 3 months ago.

Maintenance is where developers live or die by the decisions they made during development. How quickly can a bug be turned around and delivered into production, how quickly and easily can new features be added and what does adding those new features do to the current code base.

So back to our candidate. Just what is it are we looking for in a response to our question about what have they delivered. First of all I want to hear that they have delivered (obviously) and I want to hear they have delivered more than once and maybe learned from the experience. The only excuse for this is for a graduate or some one with less than 2 years experience in the industry. If you have 9 years and still haven't delivered anything into production, perhaps its about time you started asking those awkward questions such as "Is it me ?", "Am I any good ?", "Should I get a job in a super marker instead ?".

Next I want to hear about the latest delivery, what they did to ensure it would deliver. What decisions during development did they have to take to make sure deployment would be as easy as possible, where were the trade offs, the conflicts of interest, where was their contribution.

Then I want to hear about the actual delivery, and this can be a collection of deliveries showing they got something live, and then got it live again and again with defect releases and new feature releases. I want to hear about problems they had and how they dealt with them, and what those problems did to influence future work or refactoring.

When it comes down to it deployment is actually a fun activity, the number of times I have seen teams gel like never before during a long deployment process is amazing. It becomes a trial of sorts where only the team involved can make it happen and when it does go live, that team can proudly say they did it. It does wonders for moral, and that is what I am looking for in a candidate, you get them to talk about past deployments with nostalgia, like old battles lost and won, there is always a glint in the eye of people who have deployed and won !.