Harpo, Groucho, Chico.
They say Hope Springs Eternal. Let’s not push it, but there are perhaps a few more steps that can be taken on the sunny side of the software street, and a few more hints worth sharing to lower the chances of sleepwalking into another IT Shambles. Maybe it’s a post-Olympic-summer haze, maybe it’s just been a while since my last catastrophe, but joy seems to be abounding at the moment. A normal service of whinging, moaning and despair will be restored in due course.
Let Us Revise What We Know. Viz, Don’t Bolox It Up On Purpose.
I do not offer any penetrating insight on hitting the Road To Success. There aren’t seven habits, six attributes, ten behaviours or 17 ½ best practices which will ensure you deliver right-first-time, full-scope, on-schedule, within-budget at zero-defect quality. Won’t happen. It’ll always be later, buggier, more expensive and slightly more rubbish than was anticipated at the start. It’s just a question of how much. On balance, the dice fall something like this:
On that basis, “Not bad” is a towering achievement and even “A bit shit” is better than more than half the rubbish that gets kicked off. The aim is therefore to achieve “Alright I suppose” or better and we already have five handy maxims from our earlier work to help make that so. To recap in brief:
1. Don’t Replace Software That Works
2. Don’t Write Software Nobody Needs.
3. Have An Idea Of What You Are Going To Do.
4. Aim Low.
5. One Piece At A Time.
With five anti-Shambles guidelines already in the bag, let’s aim for a dozen overall.
6. Good People. All In The Same Place.
Yes, assuredly there are many clever chaps in Laos, Bolivia and Rwanda. Undoubtedly, unit resource costs would be lowered markedly via utilisation of a distributed outsourced offshore staffing model. And undeniably modern technology connects us all up in marvellous ways so that inter-continental collaboration is now truly possible.
But Just Say No. The numbers may look great in the CFO’s spreadsheet but it will be carnage incarnate in practice for reasons elaborated extensively elsewhere. The correct staffing model is very, very, very simple: recruit good people and put them all in the same place. Definitely in the same building, ideally in the same room. And that does mean everybody – all the developers, testers, analysts, managers and assorted hangers-on. Oh, and do make sure they can actually do the job they’ve been employed to do. Software is hard and you need clever blokes to work on it. Really clever blokes(*). Proper, brown-anorak-wearing, chess-playing, twitchy, remorselessly logical, awkwardly introverted boffins. They will not be easy to find, wherever in the world you look. How many kids in your year at school designed and built a digital delay unit from scratch out of bits bought from the Maplin catalogue, or spent a half-term knocking up Donkey Kong for the Spectrum ? Not bloody many, but that’s who you want. Those lads used to be the only ones who would tolerate the combination of ridicule, social exclusion, heavy responsibility and middling dosh that were the rewards for following a career in coding. Over the last 15 years the dosh has improved (though the cachet has not) and so prompted a tidal wave of duffers to attempt and in many cases succeed in passing themselves off as software engineers. The talent has been greatly diluted. Go into any IT shop in the country, chuck a half-eaten Lion Bar at random and you are about equally likely to hit a developer who is:
- or Absolutely ****ing Dreadful.
Crushingly, this drop off in productivity is exponential rather than linear. Each step down cuts it in half. A ninja up at the top end of the ladder will chop out in an hour what one of the landfill guys at the bottom struggles to finish in a month. So recruit carefully, pay well, weed out the blockheads and treat your painstakingly filtered ‘A’ grade nerds nicely so they stay and stay happy. You don’t even have to pay that well; you’ll get a similar distribution of dimwits if you lob the aforementioned confectionary into a struggling start-up where everyone’s paid beans as in the highly compensated cubicle farm of a City bank. In fact, the spods in the bank will be a fair bit worse – sacks of cash to spend, little pressure to spend it wisely, far less clue about technology overall leads to a any-old-bums-on-seat approach to recruitment (**).
If there is a real burning desire at the high level to mobilise a human wave of developers and leverage those ostensibly lipsmacking offshore cost savings, suggest moving the entire company to Kyrgyzstan. The whole damned kit and caboodle – business development, senior stakeholders, human resources, Uncle Tom Cobbley and his corporate brand creatives and all. Let’s roll out those efficiencies vertical- and horizontal-wise, right across the organogram ! Logically, strategically and financially, the board should lap this sort of thing up, especially when you tell them that this initiative must be led by the directors themselves, right from the front. It’s a very sellable proposition. Central Asia could be the next China and the entire region offers real value for money right now both in terms of salary and property overheads.
7. Get On With The Work. Do Not Prat About
When knuckling down to any thorny undertaking, it’s hard to get started. A pot of tea first. Maybe a custard cream. Watch a couple of episodes of The Rockford Files. Then lunch. Even once you’ve started painting the lounge or whatever, it is still difficult to resist the allure of the kettle, the biscuit tin, the telly and the fridge. Bring the internet into play and the opportunities for distraction multiply. Whether it’s The Empire Strikes Back remade in Lego, Facebook, pandas sneezing or Kelly Brook in her undies, it is a miracle that any DIY has been done anywhere in the developed world since the widespread availability of broadband in the home.
As in normal life, so in software but bigger, stupider, more boring, more worthless, more varied, and with top-down control plus (minus ?) whatever the opposite of an economy of scale is. Time-wasting will in general be imposed upon you from above as well as flourishing in its many natural, self-seeding forms. You may find yourself doing any and all of the following rather than getting down to brass tacks.
- Drafting, debating, circulating and approving 97 versions of a high-level design document which in its final incarnation is 297 pages long.
- Installing, reviewing, contrasting and comparing the dozens of available open source packages in a given field with the vague notion of using one to provide a feature of marginal usefulness which in the end nobody is that bothered about having.
- Producing, challenging, squeezing and validating 97 versions of a project plan which at its culmination is a 9,797 row Gantt chart, each amendment taking it another step further away from reality.
- Deciding that instead of simply copying files from server A to server B when the need arises, you will instead craft the finest generic framework known to humanity for transferring data from one place to another. It will batch, it will encrypt, it will retry, it will audit, it will translate on the fly into EBCDIC, UTF-8, Braille, Morse and Flag Semaphore and it will use any transport mechanism from carrier pigeon to the Deep Space Network via the pneumatic tube and 1200-baud acoustic coupler. Hell, if you decide you want to fax a pound and a half of Brussels sprouts to the dark side of the Moon, it’ll have a bash.
The clever trick is of course not to do any of the above: simply avoid pratting about and get on with the damn thing you were supposed to be doing in the first place. There’s no magic bullet. Just don’t be a bloody fool.
8. Beware of Salesmen Bearing Best of Breed Enterprise-Class Solutions
As a general rule, anytime anyone expends a great deal of effort trying to flog you something, it is virtually certain that the product on offer is a crock of shite. If it was fine to start with, if it offered great value for money, if it was going to do you some good, then it would sell itself directly on those merits without a load of high-gloss singing dancing multi-coloured flapdoodle.
It’s just a fizzy drink. Carbonated caffeinated treacle. It’ll rot your teeth. You’ll end up the size of a house. But hey, those 3D jitterbugging cartoon critters look fantastic.
No commercial organisation ever ran a 30 second TV spot for brisk walks, carrots, or getting up early to finish off tiling the bathroom.
What goes for gut-rot soda pop, greasy fast food and perfumed mineral oil applies just as categorically to software. If, in order to truly grasp the massive efficiency gains possible via the purchase of a comprehensive document management solution, it is necessary for a minibus full of senior VPs to be taken to Twickenham, The Royal Opera House and Stringfellows, then you’re probably about to buy and install a turd in a bag.
9. Get Hold of A User Who Can Find His Backside With Both Hands
In a modern self-important big high-building-type company, you will find any number of spivs purporting to represent “The Business”, whatever that is. They may introduce themselves to you as Business Project Manager, Strategic Data Analyst, Market Vertical Product Owner, Customer / End User Advocate, Propositional Subject Matter Expert or any other combination of lofty verbiage. These are the guys who are ostensibly tuned in to the commercial zeitgeist, who can envision(***) the forward motion of the enterprise, who will prioritise and define the Road Map into the Future. They are supposed to be the people who proxy for real customers in telling you what to do: what software to write, how it is meant to behave and which bits are more important than which other bits. Not more than three in twenty of them have in fact the slightest clue how to discharge that responsibility for which they are being paid so handsomely.
Notwithstanding the preceding vitriol, you will occasionally bump into someone who does understand what the outfit that employs you all does. And above and beyond that, is capable of translating its ambitions into a plainly worded shopping list of changes which can be easily coded up. This is gold dust and when you come across such a person you should cling tightly to their legs and never let them leave your project. Ply them with cake, drink, pills, dope, bimbos, himbos, neck massages or whatever it takes to keep them smiling on the squad. If you do have this bit of luck, you will suddenly be able to answer previously intractable questions like:
- What are we meant to be doing ?
- Is this bit important or not ?
- What do we do next ?
- Now that we’ve coded it, is it right ?
- Have we forgotten anything ?
- This bit’s still a bit crap. Shall we fix it, or is there something else more useful we could be doing ?
And in each case receive an intelligible response which you can act on, rather than some waffle about supporting leading-edge capabilities for an inspirational 21st Century offering.
It cannot be overstated how useful having a sharp user or client representative is, someone who can make genuinely sensible calls on priorities and requirements and quality. So much less time will be wasted, and the end product will be far far more useful and well-behaved. He will be able to decide whether supporting diacritics is more important than jazzing up the offline client, or whether we should worry about Checkpoint, or if it is worthwhile the team spending a month tarting up user-generated resources or what the hell have you.
If you belong to the documentation-up-the-wazoo / everything-nailed-down-at-the-start / waterfall-old-skool tendency, this may strike you as startlingly unsophisticated and childish. Naive. Jejune. You think we need to ask someone what to do when we’re already half way through doing it ? With superlative documentation signed-off, fully validated requirements locked down since June and the design ratified for over six months ?
Given time, I could probably muster a thorough, reasoned, evidence-based response to those concerns but the following clip conveys the nub of my argument with a degree of clarity and force it would be difficult to match.
With the greatest of respect, and with due consideration given to all the issues raised, I find that I must, indeed, fart in your general direction.
10. For Pity’s Sake, Test The Damn Thing
Testing is a fag. The test boxes are cheap, nasty and unreliable. Setting the code and the config and the data and the bleeding firewalls up so the wretched thing will run takes weeks. And often the poor sap doing the testing has so little grasp of the technology you might as well have engaged your 85 year grandmother. Despite her cataracts and early-stage Alzheimer’s she’d be quicker on the uptake than the Chuckle Brother you’ve been landed with. For him, the technological advances of the last 100 years, down to and including the ballpoint pen, are baffling mysteries.
But notwithstanding a scrapheap challenge of a test environment comprised of Amstrads lashed together with bell wire and crocodile clips, and even if your Test Consultant is Father Dougal, it still is vital that you test the stuff you’ve written before you release it onto innocent users. Somehow the act of installing the blasted thing from scratch and getting a second person to give it the once over will flush out serious crud that no developer would ever themselves have noticed. Two heads always turn out to be better than one, even if the second one is a sheep’s head, even if that sheep has scrapie, or even if it’s the more gormless half of South Yorkshire’s most venerated light entertainment institution.
Summary: That’s Enough Breezy Confidence For Now
My aim at the start was twelve points; I got to ten and ran out of steam. It’s not quite there, it’s not even nearly there if we’re honest but, like the airport you arrive at when you fly with Ryanair, it’s in more or less the same region. That is very much in the spirit of the limited optimism I am offering here, and it’s also in the spirit of agile development – better to do something vaguely useful and fall a bit short rather than spend 18 months pissing cash up the wall with requirements workshops, project tollgates, entity-relationship diagrams, customer journeys and high-level data visualisations.
I am slightly uneasy coming out as a fully liberated Orthodox Agilist partisan. The ludicrous fervour and zealotry surrounding Agile is inappropriate and off-putting to start with. What sane person would care that much ? It’s only work, we’re not saving the Rainforest with Sting, introducing the Word of the Lord to the Heathen or billeting the Red Militia at the Ritz. Chunks of the terminology are pretty noxious too. Scrums and sprints have an unseemly whiff of competitive machismo about them. Let’s not forget we were the kids who got picked last for team games at school. I don’t want reminding of that, or of communal showers, or the sweaty jockstraps of the bigger lads. And when it’s not getting all testosterone-heavy, beefy and ostentatiously butch, Agile seems to head right for the other end of the spectrum and become unforgivably twee, folksy and infantile. Stories ? Show and Tell ? Have we returned to kindergarten ? Shall we fish out the acoustic guitar and ethnic percussion, sit in a circle on the carpet and sing “Kum By Ah” ? It’s not right, and even an eight-year old boy would smell a rat.
But despite my reservations, in the main Agile does go with the grain of how software projects pan out in actual, dreary reality, and it fills most of the gaps that normally get left. Requirements are going to change – don’t try to etch them in virtual stone tablets at the start. Endless questions arise on what the code should do – shove the business geezer who claims to “own” the “product” in front of the developers every morning at half past nine. Impossible to predict when the project will finish – take down the eight by two by A0 five-year programme plan of record from the wall and concentrate instead on what you are doing right now. And so on.
Agile is not a panacea. Agile will not get two years worth of work done in six months. Agile will not transform a bunch of thicko engineers into genii. Agile will not stop your sales force asking you to do stupid, value-free, dangerous and complex pieces of development by a week next Tuesday. Agile will not put a tiger in your tank, make you look five pounds thinner, or give your mouth sex appeal. Sometimes, you might head off down a garden path, refactor some code that could have been lived with, or spend a month titivating a piece of work that was doomed to start with. But on the whole, it makes a reasonable finish more probable and excruciating, wasteful disasters a good deal less so.
So – there it is. Limited Optimism. Hurrah. Whoop Dee Doo. Hallelujah. But don’t get too carried away. Your next endeavour could still be absolutely irredeemably god-awful, now matter how cunning you are in its execution. You might get hired to put together the back end for the next Cones Hotline.
(*) I am extending the words “bloke” and “chap” here into universal, gender-neutral descriptions of stand-up, reliable and thoroughly sound human beings of either genital group. You only ever meet good blokes and decent chaps. A bad bloke or a horrible chap is simply inconceivable.
(**) For once, I can back this assertion up with facts, evidence and statistics. I have seen the CVs and I have interviewed the morons in their dozens and can confidently state there are thousands of guys earning hundreds of quid a day in The Square Mile who could not code up a bubble sort without having to Google it.
(***) I know. It’s not a proper word.