Trying to do everything

I had an interaction on Twitter today which got me thinking – as Twitter discussions often do, because the amount of debate possible in 140-char limits leaves many things left over to think about. I think this blog post is mainly just to make the arguments that I couldn’t on Twitter. I’m not sure that’s a good enough reason but hey, it’s my blog.

The beginning of today’s conversation was this tweet I saw: “Dear developers: to have any sort of impact in this industry — managerial, or technical — you need to know how to people.”.

Now, in its defence, the tweet is true from at least two points of view. Firstly, the status quo argument: as things are, at present, you need to have influencing skills to get anywhere. That’s true, and it’s good advice if you want to get promotion. But it doesn’t really move us forward towards anything better: is that what we want the industry to look like? Is it the way to get the best results? Does it make us better developers, worse developers, or make no difference?

Secondly, of course it’s true that anyone needs a minimum level of people skills in order to – frankly – not be an arsehole to work with. Definitely. That’s a fairly low bar, admittedly, but some people still don’t reach it.

But in a broader sense, I think that it’s bad advice. Because it’s another example of trying to do everything.

Developers are supposed to have strong technical skills. They’re supposed to know how to code, how to test, how to architect, how to analyse a domain, how to work in a team, how to write good reusable APIs, and much more. They’re supposed to keep up to date with changing technologies, new languages, and changing businesses that use the technologies. They’re supposed to know databases, frameworks and build tools, all of which change constantly. And most importantly, they need to make good judgement calls on which of many different options is most likely to be robust, flexible and sustainable in an unpredictable future. This is a high-skill profession. It’s actually quite easy to learn a programming language and get coding, but to write good-quality enterprise software is hard.

All these skills can be learned, and are learned. Partly on the job, often in the developer’s own time, and continually. And yes, people skills can be learned too. But there are only 24 hours in a day, only 365 days in a year. The more skills a developer has to learn, the less expert they can become.

This sounds like a bit of a straw man – after all, asking developers to learn people skills isn’t a huge ask – maybe it takes 10% of their learning time. So they’re a bit less up-to-date, a bit less expert in some technology or other – will it really make a difference to the outcome of the project? Isn’t the benefit from the improved communication worth it? It seems like the answer should be yes. But…

The catch is this. Once we say that we expect developers to have people skills to sell their technical arguments – which is totally reasonable – we then structure the organisation so that the best presented argument wins. It is very easy to then say (in fact, hard not to say) that the developer who explains their idea best is the best technologist. They have impact and influence. The onus is no longer on anyone else in the organisation to understand the technical issues: the best solution is the one that non-experts understand, and the best technologist is the one who presented it.

If you promote based on ability to communicate ideas, you turn your organisation into a people skills competition1. Then the people who make technical decisions won’t be the ones who spent 10% of their time to learn people skills. They’ll be the ones who spent 90% of their time to learn people skills. And that’s not enough time left to spend learning the technology.

It would be great to have team members who can do everything, who have excellent technical skills and excellent people skills. Just like it would be great to deliver every project idea and great to include every feature. Sadly, that’s not how the world works. We have to choose: to prioritise and specialise. And if we say that the best-communicated argument wins, we prioritise people skills over technical ability and we will get bad software.

Which, I would argue, is pretty much the case now.

1 Caveat: people managers should absolutely be promoted based on people skills. But they should not have the final say on technical issues unless they also have very strong technical skills.

XKCD and Password Strength

Most of my blogs start when I’m annoyed by something. In this case, this article.

I love XKCD, and it makes many valid points. However, when all is said and done, it’s a webcomic. I really doubt the author is actually expecting us to take it as literal life advice. He’s probably more aiming to make a point and get us thinking and/or laughing.

Which is why I’m a bit worried about how much this ( is getting quoted as a serious proposal. (If you haven’t seen the cartoon, take a look – xkcd is excellent). Because it makes a very valid point, but the maths doesn’t stand up in the real world.

Why? Because hackers are people, not computers. And when their victims change tactics, so do the hackers.

The current situation is this: we’ve all been trained to use random letters, numbers, characters, a mix of upper and lower case – like “a7@!f[)d5”. And you do that, right? (Right? No, me neither). So hackers will first try a simple dictionary attack to check for people dumb enough to use a plain-English word, and then they’ll try combinations similar to words with the standard replacements (“s1mpl3r”). If that fails, they can use a brute-force attack – try every combination.

Let’s look at the maths. Suppose you choose an 8-character password made of any valid ascii characters. Then the universe of possibilities is 255^8, or about 1.8e19. That’s a lot of possibilities. Now suppose you choose any 4 English words from the Concise Oxford English dictionary – about 240,000 words, separated by spaces. The average word length is about 5, so you’ll have a 23-character password. A brute-force attack has to deal with 255^23, which is 2.2e55 possibilities – MUCH better, right? That’s 10^36 times better – or 1,000,000,000,000,000,000,000,000,000,000,000,000 times better.

So should we all switch over? Sadly, no. Because if we all switch, so will hackers. If hackers know that most people pick a string of English words, they won’t do a character-by-character attack. They’ll change their behaviour to do a word-by-word attack. Then for a 4-word password, you have 240000^4 possibilities, or about 3.3e21. A bit better than the 8-character password, but only by a factor of about 100. Not too different.

Now let’s be a bit more realistic. Assume, like most people, you usually use only letters and numbers in your passwords. Then an 8-character password has about 2.2e14 combinations. Now assume you only use words in your vocabulary rather than using a dictionary: maybe 15000^4, which is 5.1e16. Again, only a little better than the current situation.

Now you can argue that there are many more than 240,000 words in the full dictionary, and if you use the full set of words the number of possibilities go up. Which is true. On the other hand, are you really likely to pick four words at random from a full multi-volume encyclopedia or are you going to think of four words that spring to mind? 15,000 is probably an overestimate to be honest.

Then again, most people aren’t using all the full range of characters to make up their passwords now. So is the option of using words worse? No, it’s not worse. For now, it’s even a little better. But if we all switch, then it’ll be about the same.

Having good passwords is an arms race. As we discover better passwords, hackers discover better attacks. There’s no magic bullet. Choose something you can live with, and be prepared to change your strategy as the attacks change. And don’t believe everything you read, especially if it was written as a webcomic.

Google founder says internet freedom under threat

Internet freedom under threat” – Google founder Sergey Brin (Guardian article)

I was going to fire off a quick tweet about this, then had second thoughts. It’s a bit more complicated than it seems. Let’s just review what Brin is arguing.

The “threats” Sergey Brin talks about in the article are:

  • governments trying to control information and access
  • entertainment industry crackdowns on piracy
  • “restrictive walled gardens” such as Facebook and Apple

So, on (i) and (ii), I’m going to broadly agree with him. Whether it’s the UK government trying to get access to all our online conversations, or China or Iran restricting what their citizens can see, I’m against it. Although even here there’s grey area, as when Germany tries to restrict the sale of Nazi memorabilia on eBay. Remember that? Pro or con? You can make good arguments both ways.

However, let’s talk about his third point. Brin’s criticizing Facebook for being too restrictive with access to the users and data it has. Well, maybe. But what does this actually mean? In Brin’s world, Facebook is evilly sitting on data it’s collected, and refusing to share, locking away information that Google could use. But in another version, Facebook is trying to protect data that users have entered on Facebook but chose NOT to share publicly. Remember, Facebook gets regularly slammed for not protecting privacy enough.

So, when Brin complains that Facebook is restricting internet freedoms, is he talking about restricting your freedom to share what you want with who you want? Or his freedom to get any information he wants about you to make profits selling advertising?

I’m not a huge Facebook fan, although I am a frequent Facebook user. There are many issues with Facebook. And there are good arguments for avoiding monocultures where everyone is locked in to using one company. But I don’t necessarily think that Facebook should have to open up my data because Sergey Brin wants it. Sorry, Sergey.

UPDATE: I’ve just been reminded what Google did when it tried to start a Facebook-a-like, Google Buzz. It began by making all your GMail contacts public.