Why Soft Skills Matter

[Let me start by saying that I'm not an expert in this field, just someone who's had to learn the hard way why people are important in software projects.]

It's rare to hear of a new software project which is clearly doomed from the start, but I'm happy to make that call over SOLVE THE FILE FORMAT PROBLEM MONTH. It's rare for me to get to the end of a blog post and think "yeah? well screw you, buddy!", but Jason Scott's post provoked exactly that reaction.

Without getting into Meyers-Briggs typing or William Moulton Marston (he invented Wonder Woman, the polygraph "lie-detector", and wrote a book with the awesome title of Emotions of Normal People), the fact is that around 50% of the population will have a negative reaction to any new idea. They will focus on the potential problems, not the potential benefits. This doesn't make them bad people, it doesn't mean that they don't want it to succeed, it just means that they are keeping an eye out for trouble. Something which might actually be useful if you're about to run head-long into a minefield.

What you probably shouldn't do is tell all those people to "just get the fuck out now".

Nor should you declare that "The project doesn't need [50% of the entire programmer community], now or ever". Huge projects need to bring people together, and for that you need leadership capable of inspiring action, not driving away people because they don't immediately see your point of view. We have a communication problem here.

Tony Finch (@fanf) made the point that "If you want to get something done, there's no point wasting energy on nay-sayers". I agree with that. I much prefer to dive into writing code and let people worry about the design after it's working. But this task is far too large for any person or team to lone-wolf it. It explicitly relies on having a broad, critical mass of participants. Wikipedia, Linux and NaNoWriMo didn't happen just because someone said they were going to; they happened because a hell of a lot of people bought into the goals of the project.

Digital Archaeology is a cool field. Projects to save old machines are fascinating and a real labour of love. Geeks seem to love collecting and systematising (ugh!) things more than the population in general; maybe that's a stereotype, maybe it's true, but either way a project like this should be putting smiles on faces from San Francisco to Tokyo and from Moscow to Melbourne. Is it?

Maybe that has something to do with the official project wiki describing a large number of potentially-interested people as "whiners".

This should be something I want to be a part of. I love puzzles, I've reverse engineered file formats for fun (and occasionally profit), I have a bunch of old hardware and software, I'm a low-level coder more than capable of tracing my way through a disassembled program, and I have the 'archival instinct' to want to hoard a perfect collection.

But I don't want to participate. I have problems of my own to work on, and you've singularly failed to make me give a shit about yours.

So long. Best of luck. I'll go my way, you go yours. Hope it all works out... but I doubt it will.

- KoW

Government IT Failure

Yet another government database project ends in disaster. £161m spent on the project cannot be accounted for. A spokesman claims that "Steps have been taken to ensure that the mistakes made are not repeated.", but isn't that the same line trotted out every single time one of these projects goes tits-up?

What "steps" have been taken? What "lessons" have been learned? And why, if those aren't blatant lies, do things keep going wrong year in, year out? Why is a government so obsessed with databases so inept at their implementation?

The Technology in Business programme and the Government IT Profession were set up several years ago to address these issues, yet what have they achieved? The policy statements for the GITs include this gem:

Enabling organisations and individuals to develop the capability required to deliver excellence through advice and guidance on embedding professionalism and using the skills frameworks, and by creating and signposting learning and development opportunities.

That is gibberish. Complete and utter tosh. Semantically empty. They've produced at least four versions of the skills framework, all talking in generalities and buzzwords. Sound and fury. No doubt the authors of that claptrap would claim I'm "not thinking abstractly" and that classification, categorisation and meta-analysis are vitally important parts of the work. Bullshit.

Databases, despite the impression all this might give, are not all that difficult to engineer. There are around 85k prisoners in the UK. I have a database with more than 170k rows across a dozen tables, used for the back-end to some web services which I wrote in a weekend. That's running, acceptably fast, on a shared server costing me a few quid a month. I'm under no illusions and know that a proper setup - redundant infrastructure, dedicated and distributed hardware, security accreditation, crypto, development and testing of the applications - would cost considerably more, but a million times more? Several thousand pounds for each prisoner in the database?

I know I'm not cut out for the civil service: I actually value results - rather than process and paying lip-service to results. IT projects aren't made by consultants and reports and policies and skills frameworks; they're made by analysts and programmers and admins and engineers. Yes, these people need some direction, but direction in and of itself cannot produce the desired system - you cannot make a database by executive fiat!

- KoW