Interview tips for that tricky developer-pharmacist role

We’ve launched a big campaign today to expand the Guardian Unlimited technical team even further — software, systems, project management, and more. You can see the online ad at http://www.guardian.co.uk/joinus. I won’t tell you that the reason you should seriously think about joining us that GU is packed full of friendly, intelligent and dedicated people. But I will tell you one small thing about how I’ll be conducting those of the interviews that I’ll be in.

The GU software team is a little different to many others. Like most teams our developers spend a lot of time understanding requirements, sketching out solutions, implementing, bug fixing, and so on. But unlike many teams our developers don’t spend any time at all surveying petrol stations, weighing pills, or being held in weird prisons run by pathological prison governors.

I’m sure that news will surprise a lot of people, because I know a vast number of developers are very focused daily on the old petrol station/pharmacy/solitary confinement side of software. And I know this because these are the questions they get asked in interviews.

I once attended an interview for a role where I was asked the pill-weighing question, set out on techinterview.org, for example:

[…] the queen gives the assassin 12 pills which are all completely identical in shape, smell, texture, size, except 1 pill has a different weight. the queen gives the man a balance and tells him that all the pills are deadly poison except for the pill of a different weight. the assassin can make three weighings and then must swallow the pill of his choice. if he lives, he will be sent back to the bad king’s kingdom. if he dies, well, thats what you get for being an assassin.

only one pill is not poison and it is the pill which has a different weight. the assassin does not know if it weighs more or less than the other pills. how can he save his skin?

I was able to answer the question only because I’d read it the previous month. Fortunately they decided to change the job spec and withdrew the role, and I was spared a working life of having to deal with royal assassins. Or brainteasers. I hope no-one’s going to tell me this wasn’t what the job was about, though. After all, what else could the interviewer have been trying to learn about me?

Petrol pump PCI’ve also met someone who likes to ask potential candidates “how many petrol stations are there in London?” I was keen to know why he asked this, since I was pretty sure he didn’t work in a company that audited petrol stations. “I want to know if they’re a good problem-solver,” he replied.

Here’s my tip for testing problem-solving skills: make the problem as realistic as you can.

Interviewing is a difficult and artificial thing. I’m sure I’m not the world’s best interviewer, but I do know that honesty and transparency are important, because without that you and the candidate can’t make the right assessment of each other. So when it comes to creating scenarios you’ll find out an awful lot more if you make the scenario as close as possible to what really happens in the job.

If you think your team members spend important time solving problems it’s a good idea to take a moment to consider some situations where that skill was important. And if you can’t think of any, then maybe problem-solving isn’t such an important skill after all.

Here are some problems I can think of right now that we’ve faced recently:

  • A really important person in the business wants something done really quickly, but they’re so important they don’t have time to explain it properly to you.
  • We need to get a particular data feed into a particular system. What are our options? And which should we choose?
  • A particular piece of code keeps throwing up far too many bugs than is reasonable. Why might that be? And what should we do about it?
  • We need to change a bit of code, but it was build 5 years ago by someone who’s no longer here. Where do you start?
  • We want to add a new feature somewhere, and although it seems like a naturally intuitive extension it’s actually disproportionately difficult to do — what’s gone wrong there?

No pills, no prisoners, no petrol stations, no foxes crossing rivers with geese. There are issues with using these situations, of course. We’d need to make a bit of an effort to work them into something that’s solvable in the confines of an interview situation. And I don’t get to show off some kind of pseudo-cleverness in front of the candidate. But I’d say both the interviewer and the candidate get much more out of the ensuing discussion. Because it does involve a discussion, not a simple one-way answer; we don’t force people to solve problems in isolation.

And one more thing about life here at GU. We do an awful lot of Java programming, so it’s not usually terribly useful for us to test someone’s use of pointers, either.

But if you do want to use pointers — or weigh pills — then it seems there are plenty of other opportunities for you.

Guardian Unlimited is hiring a Development Manager

If you’re interested in the kind of work we’re doing here at Guardian Unlimited, then you might be interested in joining us. We’re looking for a Development Manager. As an experiment I put an ad on Google Base (now expired). Here’s the text in full…

Guardian Unlimited is embarking on a concentrated effort to expand its Development Team over the next 6-12 months, and is seeking an experienced Development Manager to drive that process.

The ideal candidate will have excellent knowledge and experience of website operations, of managing a team of developers, and of hiring excellent new developers. Additionally, you will have experience of working in a fast-changing and pressured environment, with demonstrable expertise in managing change in development teams. Excellent planning and organising skills are also essential

Technically, the team practises agile development with Java, so you will need to demonstrate a deep understanding and affinity for both these areas. The underlying operating systems are Linux and Solaris, so expertise there would be an advantage.

The Guardian Unlimited workplace is very diverse with many different stakeholders, so it’s essential to be able to work with many different kinds of people and have excellent interpersonal skills.

This position will remain open until a suitable candidate is found, and ideally the successful candidate will start as soon as possible. This is an excellent opportunity to be part of an award-winning team on a product recognised for its innovation and quality.

To apply for this role you must be available to attend an interview in London, and to work permanently in the UK. If you are, and if you are interested in this role, please e-mail gujobs@guardianunlimited.co.uk and include (a) your current and desired salary, and (b) a copy of your CV.

We welcome applications from any individual regardless of ethnic origin, gender, disability, religious belief, sexual orientation or age. All applications will be considered on merit.

This role has come up because my job has expanded to encompass the whole software side, including project management and QA, so we’ve got a gap to fill.

A new Travel site, and four uses for tags

Here at Guardian Unlimited we’ve just launched our new Travel site. You’ll be able to read a lot about it in the industry press, but I just wanted to write a little what we’ve done from a technical-managerial point of view.

The project motivation is ideal

The main strands of our business are editorial, commercial and technical. But this is not an editorial project, it’s not a commercial project, and it’s not a technical project. This is something that’s been driven by all of us. Editorially we wanted to improve navigation and bring in more user-generated content. Commercially we wanted to offer more flexible advertising opportunities. And technically we wanted to exploit our content much more.

The new Travel site brings all of us together. One technical force was to exploit keywords, or tags, a bit like those on Del.icio.us and Flickr. This is a very flexible way of categorising content and hence allowing better use of it. Tags, in turn, allow us to generate much more relevant navigation and bring in related readers’ tips from our travel tips site, Been There. For example, if you’re reading about Croatia then you can also see a column headed “Readers’ top tips” which shows readers’ tips specifically about Croatia.

This is also the perfect opportunity to redesign, to better present that information. And just as we can present more relevant tips, so we can present more relevant advertising to our readers. And the redesign also allows us to shape the pages to better fit the ads — the page can close up around a small ad, and expand to comfortably fit a larger one.

Of course, there’s a lot of technical stuff involved, but a technical project is no good for the sake of it. Here, the three strands of our business were driving each other. An ideal scenario.

Aside from much better navigation and contextual advertising, and since this is a technical blog, here are four of the other (smaller) things we’ve used tags for…

There’s a page for every tag

Each tag has its own page! Here’s the page for San Francisco. And here’s the page for skiiing. And here’s one for food and drink trips.

In fact, we’ve got hundreds of tags in the system already — you can see our list of places and activities, for example. And now we’ve automatically got a page for each of them.

There’s an RSS feed for every tag

Okay, not a big leap technically, but terrific for our readers. Top right on each subject page is the RSS link for that subject. If you’re interested in an area of Travel then it’s odds on we write about it. And if we write about it then we’ve got an RSS feed for it. You can get your own personal skiiing feed from Guardian Unlimited.

We can combine tags

Tags also allow us to pull together even more really specific and relevant content. If you’re on the San Francisco page you can find out about food and drink in San Francisco. Or you can investigate short breaks in Portugal. Or water sports in the UK. Well, you get the idea.

Friendly URLs

Our URLs are usually of the form

http://travel.guardian.co.uk/budget/story/0,,991699,00.html

which is short but a bit obscure. So we’ve taken the opportunity to improve that for the new Travel site. The same article above now has the URL

http://travel.guardian.co.uk/article/2003/jul/05/watersportsholidays.budgettravel.boatingholidays

It’s longer, but we hope it’s also more intuitive. You can clearly see the what it is (an article), the date (5 July 2003), and what it’s about (water sports, budget travel, and boating holidays).

And it’s not just articles which have friendlier URLs. Here’s the URL for the Hamburg tag page:

http://travel.guardian.co.uk/tag/hamburg

and here’s the RSS feed for our Hamburg content:

http://travel.guardian.co.uk/tag/hamburg/rss

All much easier to deal with.

And one other thing…

Lots of this is automatic. But there’s one important part of tagging that’s not: the actual act of adding the tags. In theory we could use software to look at each of our articles and determine what it’s about, and so apply the tags. But that’s not going to give the best results for our readers. So we’ve made sure that all our articles have had their tags considered and chosen individually by someone who has actually read the article. That means the navigation should be spot on, and the advertising links are ideally targetted. There’s an awful lot that machines can do, but sometimes it needs a human being to add the magic.

Anyway, hope you like the site.

Javascript puzzler: throw null

I know this isn’t really the place to post code, and I’m sorry. But this is why I don’t like loosely typed languages. I was caught by a Javascript nasty earlier this week (no I don’t code professionally, this was for fun) which boils down to the code below. What you think could happen here…?

var problem_found = null;
var listener = function(event){ /* Do something with event */ };

try
{
    document.firstChild.addEventListener("click", listener, false);
}
catch (ex)
{
    alert("Problem: "+ex);
    problem_found = ex;
}

if (problem_found)
{
    alert("There was a problem: " + problem_found);
}

You might have thought that either everything passes within the try block smoothly, in which case no alerts appear, or that there’s an exception in the try block and you get two alerts — one from the catch block and one from the if block.

And you’d be wrong.

Javascript actually allows you to throw anything. You should really throw an Error. But you could throw a String, or even a null if you liked. And if your code could throw a null then testing for null does not tell you if you had a problem. In the above example you’d get only one alert, from the catch block. If your problem-resolution code is in the if block then you’ll miss it.

Advocates of loosely typed languages will say that type problems can be avoided if you write good unit tests. But the problem occurred for me because this kind of mistake was in the JsUnit test framework, and it incorrectly showed a test passing. It took me two days to find the source of the problem. It turns out that the addEventListener() method above in Firefox 1.5 does indeed manage to throw a null if the listener parameter is not a function. Try changing it to a string and you’ll see this. My mistake was to pass in a non-function. Firefox’s mistake was to throw a null. JsUnit’s mistake was to assume a null exception means no exception.

Strict typing helps avoid problems that come about because we’re human and make mistakes. A wise man in ancient China once said “the compiler is your friend”. Javascript doesn’t have a compiler, and I can do with all the friends I can get.

By the way, you may be interested to know what the statically-typed Java language does. It doesn’t allow you to throw any object, but it will allow you to throw null. And if you do that it automatically converts it to NullPointerException. An actual, proper, concrete object. I know who my friends are.

Measuring development is useful, up to a point

There’s a post from Joel O’Software regarding measuring performance and productivity. He’s saying some good stuff about how these metrics don’t work, but I’d like to balance it with a few further words in favour of metrics generally. Individual productivity metrics don’t work, but some metrics are still useful, including team metrics which you might class as productivity-related.

  • Individual productivity metrics don’t work.
  • Productivity-like metrics are still useful…
  • …but they don’t tell the whole story

Individual productivity metrics don’t work

Joel O’S states that if you incentivise people by any system, there are always opportunities to game that system. My own experience here is in a previous company where we incentivised developers by how much client-billable time they clocked up. Unfortunately it meant that the developers flatly refused to do any work on our internal systems. We developed internal account codes to deal with that, but it just meant that our incentivisation scheme was broken as a result. Joel has other examples, and Martin Fowler discusses the topic similarly.

Productivity-like metrics are still useful…

Agile development people measure something called “velocity”. It measures the amount of work delivered in an iteration, and as such might be called a measurement of productivity. But there are a couple of crucial differences to measuring things such as lines of code, or function points:

  • Velocity is a measurement of the team, not an individual.
  • It’s used for future capacity planning, not rewarding past progress.

Velocity can also be used in combination with looking at future deadlines to produce burndown charts and so allow you to make tactical adjustments accordingly. Furthermore, a dip in any of these numbers can highlight that something’s going a bit wrong and some action needs to be taken. But that tells you something about the process, not the individuals.

The kick-off point for Joel’s most recent essay on the subject is a buzzword-ridden (and just clunkily-worded) cold-call e-mail from a consultant:

Our team is conducting a benchmarking effort to gather an outside-in view on development performance metrics and best practice approaches to issues of process and organization from companies involved in a variety of software development (and systems integration).

It’s a trifle unfair to criticise the consultant for looking at performance metrics, but one has to be careful about what they’re going to be used for.

…but they don’t tell the whole story

A confession. We track one particular metric here in the development team at Guardian Unlimited. And a few days ago we recorded our worst ever figure for this metric since we started measuring it. You could say we had our least productive month ever. You could. But were my management peers in GU unhappy? Was there retribution? No, there was not. In fact there was much popping of champagne corks here, because we all understand that progress isn’t measured by single numbers alone. The celebrations were due to the fact that, with great effort from writers, subs, commercial staff, sponsors, strategists and other technologists we had just launched

A bad month then? Not by a long shot. The numbers do tell us something. They tell me there was a lot of unexpected last-minute running around, and I’ve no doubt we can do things better the next time. It’s something I’ve got to address. But let’s not flog ourselves too much over it — success is about more than just numbers.

Quality is a bogus variable

Quality seems to be widely misunderstood. People often talk about quality being a key variable that a project team can choose to alter to reshape their project — along with other variables such as cost, scope and time. I think that view is flawed. Meanwhile Mishkin Berteig is not unusual when he says “I have come to believe that quality is not negotiable” — meaning that although it’s possible to negotiate over it, it’s fundamentally wrong to do so. I think that view is flawed, too. From my position quality can rarely vary in the same way as other key project variables, is rarely changed directly, and often it is right to allow it to drop below 100%. I want to spend some time here explaining why.

Before I launch into this, allow me to say that although this is inspired by an issue on which I differ with Mishkin, I do have great respect for him. In fact, it’s arguable that I’m only writing this because I have such respect for him — because it’s so surprising to see him write something that seems to be so mistaken.

The sections ahead are:

  • Quality is about much more than bugs
  • Quality is rarely addressed at the outset
  • Quality is less flexible than scope, time or money
  • Quality is usually the driven, not the driver
  • Quality can be lowered — and sometimes that’s okay
  • Non-executive summary for non-executives

Now, let’s get on with things…

Quality is about much more than bugs

First, let’s make one thing clear: quality is not just bugs. It includes look and feel, ease of use, ease of installation, performance, and so on. Looking at Mishkin’s post it’s clear to me that we he says “quality” he really means “bugs”: he is making a strong case for test-driven development. But test-driven development doesn’t help with an application that requires six clicks rather than one to enter the default data. It doesn’t help that one of your modules needs administrator access to save its state. It doesn’t help that you can’t add any more servers when you need to triple its capacity. These are situations where quality could be improved, but which aren’t solved by test-driven development. Quality is wider than that.

Quality is rarely addressed at the outset

There’s a classic project management mantra in many variations: “cost, quality, time: pick any two” is one such [1, 2 (PDF), 3]. At one level it implies (quite fairly) that the major project variables at the outset are interdependent, and you can’t choose settings for them all. You can’t say, for instance “I want it to do all this, I want it to be flawless, and I want it in a week” — making just two of those demands determines what you get for the third.

But at another level it suggests that people are making these kinds of decisions, and that quality is often determined at the outset. I find this implausible. I rarely hear clear requirements at the start of a project about the quality of the result. I’ve heard vague pronouncements, but rarely anything that could be factored into a project plan. I’ve heard “we need to do better than last time”, and “let’s not over-do it the way we did before”. But that’s usually part of an agenda-setting speech, not the project plan. It’s not enough to help make a calculable impact on scope, cost or time.

At the start of a project you will hear a precise number for a budget, a strong date for a deadline, and (we hope) a clear list of requirements. But it’s very rare that people give a precise level of quality — it doesn’t even have a common unit of measurement (remember: quality is not just a bug count). Quality is rarely negotiated at the outset. The client expects the software to do the job specified, and that’s that.

Quality is less flexible than scope, time or money

Another misconception is that quality can be varied to the same degree as other major (initial, or input) variables such as scope, time and money. Scope can be cut right back, or added to indefinitely. Similarly for money and time. But quality doesn’t vary in the same way. Quality can’t be increased arbitrarily — after a point there’s nothing left to do, assuming the scope isn’t changing. Similarly it can’t be reduced to zero, because below a certain point — well before you get to zero — the product isn’t doing the thing it was supposed to do and therefore you’re reducing scope.

However, while I believe that quality varies less than other project variables, I do believe the consequences of improving quality — even a small amount — are significant. Unit tests reduce firefighting and ensure the project is always moving forward. Usability testing ensures people are much more comfortable and confident with your software, paying dividends throughout the business. Increasing quality by a small amount can have a big, positive knock-on effect.

Quality is usually the driven, not the driver

I’ve talked about scope, time and money being “input” or “initial” variables. They’re things that are usually explicity set at the start of the project. Quality, however, might be set early on, but it’s usually determined by other things.

Sam Newman writes, correctly in my opinion, that quality is driven by process. Here, they way you do things determines how good the result is. Quality is an “output” variable more often than not. Introducing test-first development is a process change; allowing post-development testing time to be reduced because the development phase has overrun is a consequence of an unfortunate project management process; introducing or eliminating performance testing is a process change. In all these cases quality is not an independent variable; it is driven by other things.

Quality can be lowered — and sometimes that’s okay

Quality is negotiable, and it would be foolish if it wasn’t. It would be foolish if budget, scope and time weren’t ever negotiable, but they are, and in that respect quality stands next to them on a level.

Real situation: The website is being built; the investors are making bullish noises in the City; the launch — a release and public demo — was scheduled months ago and is due next week with 200 big media attendees, and testing is still on-going. If a real, but infrequent, bug is found that can’t be fixed by next week does the company cancel the launch?

Real situation: You’ve been working for months on your release. It’s almost done, but there’s another project looming, which the sales team are desperate get started. The time remaining for your current work will leave some untidy edges, but there’s a pressing commercial need to release it and move on to the new project before the company loses more competitive edge than it already has. Do you push for a project extension?

If a developer tells me their professional needs are bigger than those of the organisation in which they work, then they shouldn’t be working there. A developer works for their organisation — just as everyone in that organisation does — not the other way round. And making the right decisions for the business must have positive consequences for the development team.

Mishkin says

Every time the developers sacrifice quality for schedule/cost/features, they incur a debt. Sometimes this is called “technical debt”. I like to call it lying.

Powerful prose, but I’m afraid that particular extract strikes me as uncharacteristically arrogant. “Technical debt” is an honest term. By using this term the developer says to their organisation that the decision taken now will incur an increased cost later. The organisation as a whole can then weigh up the options and make an informed decision. And call me crazy, but it might just be that after being appraised of the situation, the project board, or managers, or directors might be in a better position to make a strategic decision than the developer who’s paid for their expertise in one very particular part of the organisation.

Of course, that’s not to say that every decision on quality needs to be raised to board level. Just as a developer wouldn’t dream of bothering their project board as to whether they should use descriptive variable names (“Well, short names are quicker to type and might shave off 2% of our delivery time, but longer names will save us time if we need to revisit that part of the code…”) so there will always be ways to improve quality in refactoring, or configuration, or packaging, or architecture which the developer should just do without question because they’re a professional. But the developer who never informs their project board of major quality forks in the road, and who never allows their client to be involved in such decisions, is failing to fulfill their responsibility as a member of the whole project team.

At Guardian Unlimited we’re always looking for ways to improve the quality of what we do. But I’ve also heard people say “let’s not gold-plate it”, and “look, we’re not producing art”. These are senior developers who are arguing against particular quality improvements because they are able to weigh up not just the technical decisions but also the wider business decisions. They are being pragmatic. I’d say they are much better developers for it.

Non-executive summary for non-executives

Let’s recap. Quality is really important. It’s about much more than unit testing. And making small increments in quality can result in disproportionately large increments in the results. But let’s not kid ourselves that quality is a variable that can be tweaked arbitrarily and independently this way and that. It’s not of the same standing as budget or scope or time. And let’s not kid ourselves that developers of principle have to stand firm against some kind of management beast constantly trying to undermine them. Developers are an integral part of the organisation, and should behave (and be treated) as such. The quality of developers’ output needs to be balanced just as every other organisational demand does.

As long as we can see and understand software quality for what it really is, the better we are able to improve it.

The benefits of OO aren’t obvious: Part V of V, evolving the product

Previously I wrote:

Sometimes you work with something for so long that you forget that other people aren’t familiar with it. This happened recently talking to a friend of mine — “I’ve got no need for object orientation”, he said, and I was shocked. […] What, I wondered to myself, were the benefits of OO that he was missing? How could I persuade him that it does have a point? So here is my attempt to trawl my memory and see how I’ve changed in response to OO, and why I think it serves me (and my projects) better. In the end I’ve found that the benefits are real, but nothing I would have guessed at when I first started in this field.

I’ve already written about data hiding, separation of concerns, better testability and refactoring. Now read on for the final part…

Evolving the product

The final advantage to OO: it’s easier to evolve — hell, just to change — what you’re producing. Now ideally this shouldn’t matter. Ideally you’d get your requirements, your client would say “I want to this, this and this” and off you’d go, and then you’d produce something which the client is delighted with first time. That works in a waterfall environment, an environment where things are predictable and don’t change, but not in most cases. In most cases the client changes their mind, or adapts their ideas, and that’s just reality.

Note that I’m not talking about the so-called advantage of OO that I’ve often heard cited, and never really believed: that it’s easier to capture requirements with OO because it better models the world. To me the advantage is in tracking changing requirements.

I think OO deals with this better because people’s thinking evolves around things more than processes, so the amount you have to change your code is roughly proportional to the amount of rethinking your client has done, and their idea of a “small change” will at least be closer to your idea of a small change.

Again, this doesn’t come for free. You need to keep the structure of your application running in parallel with the structure of the client’s thinking. This takes experience and some work. But at least you’ve got more of a fighting chance of success than with a procedural language that’s already one step removed from people’s thinking. In particular domain driven design is all about ensuring the structure of software keeps up with how clients understand their domain, with the express aim of making change much easier. And of course being able to refactor with confidence is an important part of that.

Why wasn’t all that so obvious?

If you’d have asked me five or ten years ago about the benefits of objected oriented programming I could have cited the theory but wouldn’t have really been able to justify it. Data hiding is helpful, but probably doesn’t warrant changing your language — and your thought process — alone. But ideas such as dependency injection, refactoring and domain driven design are things that have come to prominence only relatively recently. They’re where I see the real benefits, and none are obvious from the atomic concepts of OO.

None of this means OO is always the right answer. If your requirements are solid and your domain is well understood then lots of the above advantages are irrelevant. But most of the time that isn’t the case, and it’s then that object orientation can show its value.

It’s odd to me that OO’s benefits are really only tangible years after it’s come to prominence. Perhaps it takes years for us as an industry to really understand our tools. Perhaps it’s only after the masses have taken up a technology — and produced an awful lot of badly written software — that the experts will come forward and really explain how things should be done. Or perhaps I’m just a very slow learner.

Whatever the reason, I can at last explain why I think OO is a step forward from procedural languages. Even though it’s not obvious.

All installments: