Quite often when I talk to people about IT development, how projects should be run in order for them to be successful, I use building as an analogy. Let's say you wanted an extension on your house or even a new house. First of all, you'd have to have a think about what you wanted and then you'd probably talk to an architect. The architect will listen to your requirements, perhaps set you straight on a couple of ideas and possibly make a couple of suggestions of her or his own. This is analogous to the stage of an IT project when we first engage with a client and make our proposal.
At some point more detailed plans are required - showing, perhaps, where the outflow pipe from your jacuzzi will run - and this is equivalent to our systems design, the specification that is written by a systems analyst. This stage of the process, which I wrote about a few months ago, is critical to the success of the project. It details our understanding of what the client has requested and we won't start work until that document has been signed off.
So far, so good. We've reached this stage by talking to the client, starting in broad conceptual terms, then getting into more detail and ultimately documenting the project to the point where they can say "Yes, that is exactly what I want. Build it!" On our side, we will have worked out precisely what's involved so that we can give an accurate quote for the work and, crucially, plan the work into our schedules so that we can tell our client precisely when the work will be delivered. It is this process that is a key part in making good on our promise to deliver IT systems on time, on budget and to spec.
It is at this point, then, that the developer gets involved and, if you're not careful, this is where it can all go horribly wrong. You see, being a good developer is about so much more than being able to write code. In fact, in some ways, that's the most trivial part. When we interview for developers at Meantime, we assume they can write code or why else would they be coming for a job with us? (Which isn't to say that they don't get a thorough technical interview from Steve!) The qualities that we're looking for before we employ someone are a little harder to pin down. But I've been in IT for 25 years now and I have met an enormous number of developers, and in this post I'm going to detail some of the things that I think contribute to making a good developer.
One of the most important qualities is sense of place within both the team and the business. One of the worst developers I've ever worked with described himself, without irony, as "the talent". A good developer recognises that he or she is part of the project lifecycle. They appreciate the work that has taken place before a project reached their desk and also respect that work. A developer who thinks they know better than their colleagues or even the client, is not going to deliver what has been promised to the client.
And this sense of place should come from having empathy, which in turn should lead to some serious consideration about what the end users' experience of the software will be. Using good software should be like reading a good book; you should be barely aware that you're doing it. It should be intuitive and responsive. In fact, it is this consideration that has made Apple's products so successful over the years and which is the major flaw with Windows 8. A good developer will put himself in the users' shoes, thinking how will they know what to do, how can I help them through the process and how will I let them know when they've finished? As I've said elsewhere on this blog, the user interface is 5% of what the developer does but 100% of what the user sees.
A good developer will also be a team player. That's a hackneyed term, I know, but it's a useful one. In many ways this is an extension of my first point but a good developer will work well in a team in several respects. Their code will be well laid out and well commented in order to assist any developer who comes to amend it later on. They will respect the change control process, such that their work doesn't overwrite anyone else's - so this is that sense of place, again - and they will understand where they fit into a project, respecting what their colleagues are doing. A good developer will be happy to share knowledge and enjoy teaching. (Conversely, a bad developer won't share information.) A good developer will also take feedback - whether it's from the testing team or from the client - in a constructive way, understanding that it is a contribution to the process.
So that sense of being a team player also extends out to the people in the company who aren't developers and out to the client too, because any project is a team effort that involves the client. I'm always warmed listening to Meantime developers talking to clients, being friendly and helpful. And that sense of being a team player also manifests itself in making the brews!
Perhaps one of the more specific characteristics that I believe goes to make a good developer is finishing. That sounds a bit odd but you'd be amazed how many developers don't finish. I think this comes sometimes from not being clear about what they're required to do (which is why a good spec is required) or perhaps just because they can't stop tinkering! Over the years I've seen many a developer convince themselves that they have nearly finished a piece of work, only for it to run on and on. And these developers also seem to end up with more bugs being raised against their work. An understanding of what a piece of work consists of is essential to being able to plan it and also to knowing when it's done.
This list may not be exhaustive, but there is only one final pair of characteristics I want to mention: enthusiasm and enjoyment, and I think these are probably two sides of the same coin. I can think of countless times over the years when our technical director Steve has shown me a piece of work that he's pleased with and even this month he has surprised me with a beautiful little piece of a user interface. Simply beautiful. Readers of our newsletter and our followers on Twitter will be aware of Paul's brilliant work in turning a Raspberry Pi into our office Jukebox. You might think that building web pages is just about laying elements out on a page but, in addition to being a great designer, Lou soaks up HTML5, CSS3, W3C compliance and DDA with an appetite that never fails to impress me. The evidence is there in the tens of thousands of lines of code that Danny has written for one of our largest projects and, most rewardingly for me, in the stunning progress that our junior developer, Jack, has made: he's now working on live projects and that's months ahead of what I expected.
There are other people who make a huge contribution to Meantime's success, none of whom I would be without, but this post is about the developers and, as I think you can probably tell, I'm delighted by the team that we have. A bad developer is like a bad builder; they leave you with disappointing results that can cause you problems for a long time after the job should have been finished. It may be obvious to say that to have a successful IT project you need good developers but there is a further point here: you need a good team. This is why I'm strongly against outsourcing and off-shoring because that team should include the client, too. Recently, the sponsors of a project we're doing at Heathrow asked whether the developers on the project would like to come down to visit. More than anything else, that told me that Meantime has great developers who do a lot more for the business than just writing code.
