Andy's Mind

After my last posts I did get asked how I convince clients to go for agile software development services we offer instead of fixed bids and waterfalls. Well, it is not easy and it is worth a longer post which I’ll write one day. So for now, since it’s late and I’m tired, just a few words about clients.

My experience shows that to accept agile development the prospective client has to be agile in his ways too – even if they never ever heard of Scrum, XP or Agile Manifesto. That is they have to understand and accept that what they do is an inventive process, hardly as predictable as it is portrayed by snake oil vendors and hence inherently risky. Instead of giving their project away to experts for a fixed bid and hoping for the best a good “agile client” wants to stay on top of his project, wants to have a say, get involved and be able to change direction or add new ideas.

This mixture is, indeed, not as frequent as I would like it to be. And this attitude is almost completely absent in governments and large corporations. Because of that I don’t even try to sell agile projects there. Some brave souls did succeed in this waters, but I stay away from them – for the time being. So if you try to sell an agile project to company of 1000 people or more (and it is not Google, Yahoo, BT or one of the other corpos known to use agile) you are going to have a hard time and little chances of winning.

Fortunately, most clients do not fall into those categories. Most clients are privately owned business of various sizes, who thanks to web technology can afford now to have a system custom developed for them. And they are spending money that is perceivably theirs, which means they want to spend it well and control where it goes. They understand much faster than corporate managers the benefits agile gives them and hence are more likely to go for it.

So, for now I’d recommend going after medium-sized, privately owned companies with a pressing need for a custom system unless you’re an expert salesman able to convince a corporate behemoth not to behave like one.

“If you can’t measure it you can’t manage it” said someone – and everyone repeats ever since. Part of that is a mania for metrics, which affects also many in the software industry. Those affected by it uphold that without measuring KLOCs, defects per KLOC and all other metrics it’s not possible to deliver good software. There are some very scientific discussions going on LinkedIn Answers and elsewhere about which of the cryptic sounding metrics is best and should be meticulously applied, usually using some quite expensive tools.

I would rather say that you can’t manage anything until you first know what you want to get and what is it that you manage. People trying to apply metrics, especially automated metrics, as a tool for managing software development do not realize that programmers are not machines and software is not made, it is created. Hence all the management methods , theories and measurements right for the assembly line just don’t apply.

Managing programmers is quite a different challenge – someone said it’s like herding cats. There is a lot a good manager can do, but metrics of any kind can be only of minor help. The biggest challenge is to get bright people who care for the code – and get them to care for the code they create for you. If they do they’ll apply all the right engineering practices. If they don’t no metrics will help – the result will be crap.

It’s not that metrics are useless. They do show something. Bugs should be tracked and maybe counted. Percentages of all kinds can be counted as well. However, they are just an indicator of something – and not the most important one. And they are just a side tool, not the product. They should never be blown of their right place or context. And never ever should any  of these metrics be be linked with a reward/bonus system.

Why? Because good software is a bit like a good meal or good architecture. It’s something that can’t be strictly measured. Good code is, for example, usually a smaller code. So measuring programmers output in lines of code makes no sense whatsoever. A programmer that introduces many bugs might be worth his weight in gold because he might be good in introducing creative solutions to the software. Just metrics won’t tell you that.

“Not everything that counts can be counted, and not everything that can be counted counts.” read on a plaque in Albert Einstein’s office. Metrics-maniacs should keep that in mind when they get too carried away with their bar charts.

I did a lot of hiring in my career, but most of that during the last two years when I was almost constantly looking for people to fill different positions. Now I’m looking for programmers for my development company I co-founded with a friend, so almost every week I’m interviewing someone, reading CVs etc. Here is what I think about it.

In a nutshell: I’m just looking for people who are passionate about the work they do. I deeply believe than to do a job right, any job, one has to like it. Better even – love it. Not all jobs are lovable, that’s true, but I think almost all jobs can bring satisfaction, can be liked.

In any case software development surely is a job that can be loved. And if I want to have a great team it must be made of people who just love to code. That’s what sets apart mere craftsmen from artists – a passion for what they do. That passion brings the desire to do things well, to care about the code they write – and to develop themselves.

That’s another important point I always look for: I look for people who want to grow and evolve. It brings me deep satisfaction if I can help someone grow. Even if they’ll leave my team some day I want to be the bright point in their career, someone who helped them reach new heights and abilities.

People I look for have to be highly intelligent and good in abstract thinking. However, I view pure intelligence as something akin to raw CPU power – intelligence is not enough. It needs passion and willingness to learn and grow to be a really good developer – or in fact any knowledge worker.

And I don’t look for narrow-minded specialists, who just can code but you can’t talk with them intelligently about anything else. Surprisingly, I haven’t yet met a good developer (or any knowledge worker) who would not have broad interests, would not read some kind of literature or do something besides just computers. Having other interests doesn’t just show one’s mind is capable of handling more than just one narrow specialty, it also helps in our work. If one thinks broadly one perceives more.

So, when I talk to people on interviews I try to feel them, to understand what drives them, what is their passion – and how ready they are to learn something new. I don’t care about formal recognitions – university diplomas & other similar paperwork doesn’t impress me. I’m just looking for this spark of interest, for this passion for what they want to do, for a bright, willing mind I can communicate with. I think this can make up for any formal training or experience. Someone capable and willing can always learn a technique, algorithm, language, theory, methodology, practice – anything.

Granted, someone who is young, never had a job and is a student won’t be immediately as productive as a seasoned pro. But he might be much more willing to learn, he might be ready to try much harder. And he’ll catch up pretty quick.

To sum it all up: I think there is too much theorizing about hiring. For me it boils down to looking for the best or those who want to be the best and are ready to put in the sweat needed to become the best.

Adam showed me this web site the other day where they protest the idea of certifying agile software specialists. He agrees with the points made there – and I do too. We just don’t agree on the conclusion.

I don’t think certificates are all that bad because I do accept the imperfect reality we live in. And that reality is that a) there are (quite many) people who believe some kind of paper with a stamp on it (like a university degree for example) defines what someone is capable of and b) because of the pace the world moves at almost no one has time to properly evaluate candidates for a job as complete human beings (hence what I call “database hiring“).

Because of that it is a fact, though sad, that the more certificates and abbreviations around your name you have the more you are likely to get hired. That’s why people do invest in getting degrees and other certificates and it is a sensible, rational investment in their careers. It won’t replace real knowledge and experience, but it so much easier to get past the door and show them if you have some paperwork.

But from the employer’s point of view certificates have some positive aspects too. Some of them are hard to get and require some real effort (like some university degrees or things like PMP). While that doesn’t automatically guarantee a potential employee will indeed perform in the real world it makes it more likely – and that counts. It also shows some dedication to the chosen profession or specialty and willingness to spend time, work and – yes – money to better oneself, get new knowledge etc.

Last but not least – not all trainings are bad. But getting your employer to pay for your course might be easier if besides something as intangible as knowledge you bring back something to adorn the office wall – like a certificate. I know no one will admit that – but isn’t it so? Again it seems those indeed stupid pieces of paper have a use.