Many is the time I have been sat down in an uplifting company meeting and been informed that Our People Are Our Greatest Asset. No-one is quite gauche enough these days to use those exact words but the sentiment is rejigged and re-released every six months or so. The packaging changes, but the content stays the same, like Elton John records, women’s magazines or fizzy cola drinks. Sometimes the speaker is sincere, but given the combined frequency of (a) uplifting company meetings and (b) jobs being ruthlessly outsourced to lower wage economies, oft-times he must be lying through his nicely capped teeth.
In the general run of things, therefore, Our People are not always Our Greatest Asset. The workforce of the late unlamented British Leyland Motor Corporation(*) springs to mind. However, in the specific case of software development, this rusty, barnacle-encrusted cliché is apposite, so long as we are discerning. Good techies are vastly more effective than poor ones and many large computer systems are kept going only by the brains of a dozen or so absolutely key ninja-level geeks within a staff of several hundred. If your aim is to run a nifty development shop then you need to recognise, employ and retain such people. But if on the other hand you are aiming for a dismal shambles where design, output and quality can be compared unfavourably with that of Longbridge(**) circa 1978, then your needs are different. In this case, rubbish people will be your greatest asset.
If you truly, genuinely, sincerely want to ruin a software project, hire the dimmest developers you can possibly find. There is no shortage of software engineers of near non-existent ability who miraculously remain in well-paid employment. I blame dot com and Y2K. Up to the mid 90s, software was like teaching. The pay was mediocre and it had the same nerdy, unfashionable, trainspotting, brown-anorak image it has today. You only worked in software if you enjoyed it, and that tended to automatically self-select people of at least reasonable calibre.
In the latter half of the 90s, the industry expanded and pay rates improved. This meant lots of clever folk considered a coding career where they would not have previously. Which was nice. But at the same time truckloads of people were enticed into software who really had no business anyway near code. They didn’t have the natural bent for it, and should have stuck to working as aromatherapists or freelance flower arrangers or whatever it was they did before their one year MSc conversion courses. So suddenly we had a large domestic population of sub-standard programmers. EU enlargement and the UK’s Highly Skilled Migrant Programme have ensured that that population can be replenished from overseas. We have successfully globalised incompetence.
So it’s going to be easy to find the developers you need to knacker your project. If you want to make certain that you end up with the hopeless candidates, follow these five easy steps.
1. Don’t Test.
Coding isn’t something you can mug up over a weekend. Neither is it a talky, touchy, feely, soft skill. It’s hard. To write code well, one must be fluent with variables, functions, algorithms, syntax and conditional logic. Not many people are, which is why recruitment is difficult. But helpfully, writing software is a completely deterministic activity; what is written either works or it doesn’t. Because of that, you can discover pretty quickly how well someone can code using a simple written test. Cobble one together over a few sides of A4: a spot of debugging, some programming exercises and a few questions on requirements and analysis. If you’re really keen, get a few of the lads in the office to sit it, see how they score and rough out a marking scheme based on that.
But if you want to pick the dullards, don’t under any circumstances do anything as elaborate as that. Just have a nice chat, and don’t ask any hard questions.
2. Box Ticking Buzzword Bingo
Assign candidates a score according to how much impenetrable jargon they have on their CV. Score double for acronymic technologies you have never heard of. If you find a fellow who’s used BodgeIT 3.6 within the Bifurcated Splurge framework to leverage synergies on the SnurGOX-52 platform, he should be a shoo-in.
It’s easy to acquire (or affect) a shallow understanding of dozens of tools, languages and bits of kit. If you judge on this basis, you will net the CV-stuffers, the bullshit-merchants, the dilettantes and the technofreaks – the clowns that can’t write a single class patch without pulling in a couple of dozen funky 3rd party libraries.
Based on the CVs I see, and the way recruitment consultants gauge and promote candidates, this method is widely used across the industry. So you’ll be bang on trend.
3. Stamina over Smarts
A counter-intuitive one, this. Picking candidates whose previous experience matches the technologies and business you’re in would seem to be exactly the wrong thing to do if you want to make a hash of your project. But software’s a funny game. There’s a lot of folk that have 15 years experience with PHP or billing systems or whatever and seem to have learned less than you or I would in three months. Conversely, you bring in a Tefal-headed refugee from academia whose only experience with software is the mathematical model for protein chain synthesis he knocked up during his PhD and within weeks he’s kicking out top quality code like an old lag.
The trick here is to (once again) ignore innate ability and choose on the basis of endurance. Get the guys in who’ve spent decades plugging away at a job they’re no good at. Again, this method is used and endorsed by recruitment professionals worldwide so no-one will suspect your hidden software-shambles agenda.
4. Look for mavericks.
You may look for idiots but find only respectable engineers. Do not worry. Your task now is to find capable people who are terminally handicapped by their quirks. There are many such. We techies are a bohemian, oddball crew and often have strange habits and peculiar approaches to everyday life. Despite these foibles, some of us manage to be highly productive. But some don’t. You need to find the bright bloke who cannot fix the simplest bug without rewriting 17 unrelated modules. Better yet, the brilliant but misguided woman who is unable even to reach the point of writing code until she has invented a new six-layer component-based architecture model into which her fix will fit. If you can find a few of these, it’s actually better than having useless people. Developers of limited ability will at least dive in and try to write some to-the-point code, even if it’s awful. By chance, they will get it right once in a while and so some useful work will get done. But gather together a rabble of highly intelligent but fiercely eccentric weirdos and you’ll be arguing about standards and frameworks and paradigms and separate deployability for months without end.
Many IT folk like to be thought of as mavericks, and the word itself can be a badge of pride. For me, it’s a synonym for nutter.
5. Never give anyone the heave-ho
An obvious one, this. Having found your crack team of hopeless cases, don’t let them go and don’t give them any reason to leave. Never get rid of any new starters at the end of their probation period. Avoid those difficult conversations with staff that start “I’m sorry to have to tell you this, but …” Make sure you cheer the team on regardless of performance. Naturally, don’t single out anyone for reward if they rise above the general morass – you don’t want to upset the others. Any promotions should be at random, or on the basis of length of service.
Beyond the basics, there’s a whole host of devious mechanisms that you could use to squeeze people out. Targeted redundancies. Compromise deals. Kicking people sideways. Department reorganisations to sideline the dodgy boys. Rank and yank. But these brutish devices are not for you. The only person leaving your outfit will be the sharp, dependable lad who’s been carrying everyone else for two years.
It took Eddie Cochran just Three Steps to get to Heaven. We have taken a couple more than Eddie, but I think we can agree that the end justifies the means: a Dream Team of fruitcakes who could turn the implementation of a bubble sort into a tortuous nightmare.
(*) For younger readers, British Leyland was a state-owned car manufacture which by the mid-70s had accumulated most of the UK motor industry. It was famed for shoddy build quality, terrible industrial relations, low productivity and poor, uninspiring, outdated design.
(**) Longbridge used to be one of the largest manufacturing sites in the world, and was synonymous with car production in Britain for almost 100 years. It became famous in the 1970s for militant trade unionism. the archetype of British industrial decline and workplace strife. In Leyland ownership and under the regime of legendary union convener Derek “Red Robbo” Robinson, there were 523 separate stoppages between 1978 and 1979.