Bing and The Andrews Sisters. The acme of Hollywood Golden Age Über-cheeriness.
Take a look at the modern world and it’s many wonders. You needn’t search far. Gathering dust on a bookshelf or buried under a pile of magazines on the floor in your living room is undoubtedly a discarded mobile phone, cast aside for something sexier, smarter and more app-tastic. I can see two such from where I’m sat now. One, the year before last’s model, will do the internet and has a slide-out keyboard. The other one, a year or two older, now seems pretty basic: the camera boasts a measly two megapixels, for example. You could buy something rather better from Tescos for less then 15 quid today. Now. Despite being a museum piece that would be sniggered at by teenagers across the western world, it is in point of fact a genuinely magical device. You could be hiking, half way up Pen-y-ghent, and take it into your head to give your mate in California a ring. Your pal, with a similarly antiquated bit of consumer electronics in his back pocket might be at home, cruising the mall or skiing above Lake Tahoe. He could even be sunning himself in Hawaii or away for work in Sydney. Regardless, your call will find him in seconds and you can talk almost as easily as if he were in the next town. The fairly modest signal delay is the one clue that he isn’t.
If you stop to consider how many bits of code, kit and wiring have to work in order to get this to happen it is breathtaking. The phone itself has to make the connection, digitise the audio signal and ship it off in packets to the base station. The base station has to handle traffic for scores of active phones, agreeing on frequency pairs for each one and handing over connections to neighbouring cells as callers move. Beyond that your call is switched and multiplexed up the wazoo across national and international telecoms networks along with a gazillion others and at some point travels 2,500 miles under the Atlantic Ocean in a little glass tube encoded as pulses of light. It is quite, quite unbelievable. Even more unbelievable is that the devices that allow you to do all this weigh less than four ounces, that they and all of the bits in-between work reliably all of the time, that the call will cost you just a few pence (*) and that all this wizardry happens for the tapping of a dozen or so numbered keys.
The point I am going three times round the houses to make here is that there certifiably are technology projects that do succeed. All of ’em include substantial chunks of hand-crafted software; some of them are almost entirely code. Beyond telecommunications, think of the Amazon site. Garageband. Google Earth. Google Translate. Google Maps. Google Bloody Anything. Type “Vietnamese restaurant in Copenhagen” into Google and within three clicks you can be virtually standing outside any one of the dozen available peering in through the window. Another click and you’ve got walking directions from the central station. Another handful and you’ve bought train tickets all the way there. It’s insanely fantastic. Ergo, a dismal software shambles is not preordained. In a break from the established pattern of moaning, wailing and gnashing of teeth, I can reveal that there is Hope.
First Do No Harm; or, Don’t Bolox It Up On Purpose.
Outside the exotic climes of your Googles and your Apples, in the lower rent / social housing / borderline slum IT neighbourhoods the rest of us inhabit, things still can go OK on occasion. Even bits of code with my grubby fingerprints on have eventually wobbled into production and run without too much pain for numbers of years. What distinguishes these humble successes from the never-ending motorway pile-ups ? My own personal Great Insight on this point is that the good projects don’t deliberately set out to make an arse of it. But what specific arse-ups should one strive to avoid ? I offer the following handy checklist of Dos and Don’ts.
1. Do Not Replace Stuff That Is Working.
Working, useful software is a rarity. All the more so if the job it is doing is complicated, runs 24 hours a day and handles thousands of transactions and users. If a system has chugged along carrying some such heavy burden reliably and without fuss for decades, it really should be treated with the respect due a venerated national treasure. This is a Ford Transit Van, a London Tube Map, a Fox’s Biscuit, a veritable David Attenborough amidst a throng of nasty programmatic Austin Allegros, Amstrad Midi Systems and Bastard Bleeding Useless Ever Ready Bike Lights(**). This longevity should be borne carefully in mind when considering its replacement. Endurance ought to be respected in all things, but doubly so with code. Code doesn’t wear out. It is not noticeably subject to subsidence, metal fatigue, dry rot or termite infestation. Quite the opposite: bugs are fixed, nifty features added, and wobbly, unreliable, grindingly slow or just plain nasty areas are over time tidied up and rewritten. The system you end up with after 10 years of incremental development will be 10 times more resilient, flexible and capable than the version you started out with. Software, like George Clooney, only improves with age
All of which means that the antiquated legacy bag of spanners which your Enterprise Architects are now sneering at is going to be very, very difficult to match and replace. Those painstakingly tuned algorithms. The hundreds of ad hoc business rules analysed, coded and refined over the years. The thousands of special cases requiring irregular, non-standard treatment. The endless tweaks for robustness, speed and reliability. Be very wary. If it ain’t broke …
2. Do Not Write or Install Software That Nobody Needs.
Best illustrated with examples. Think several times before getting mixed up with any of the following types of racket:
1. Integrated enterprise project portfolio management solutions. There are already too many of them. They are all terrible. They do not and will never do anything of worth. Anyone who has ever been forced to use one of the buggers will froth at the mouth merely at the name of the wretched thing. Better the users carry on muddling along with Excel and email(***).
2. Integrated enterprise management information and reporting solutions. Again, far too many already. Not objectively nasty per se, but overdone. Just write some queries, give ‘em the CSV files and have them muck about with the data themselves in Excel(***).
3. Homebrewed bespoke frameworks for logging, encryption, single sign on, message handling, content management or any one of the dozens of other areas which are by now 100% fully solved software problems. Yeah yeah needs are highly specific, blah blah special circumstances, rhubarb rhubarb unique environment. Pull the other one. Just download the bog standard gubbins every other chump uses off of the internet and have done with it.
4. Meta-software. Software that doesn’t do anything you can put your finger on as such, but which claims to deliver a foundation on which you can build to enable something fantastic to happen somewhere in the ill-defined but undoubtedly rosy future. Business Process Management suites. Enterprise Resource Planning toolkits. Governance Risk & Compliance platforms. Bluntly, any TLA-described software suite of mysterious and elusive benefit marketed by and to Big High Building-type Companies should be given a very wide berth. Most of these offerings boil down to a six figure long con in which a small gap that could be filled cheaply and easily with Excel and email(***) becomes a vast canyon only partially pluggable by oil tanker loads of eye-wateringly expensive hardware, customisation, licence fees and consultants.
The list above is not exhaustive. But what Dr. Spock said about parenting applies equally to IT projects: you know more than you think you do. If it feels pointless, it probably is.
3. Have Some Idea Of What You Are Going To Do Before You Start.
If you have followed maxims 1 and 2 above, this should drop out. If
(a) there is a tangible need, and;
(b) there isn’t kit already available which does the business reasonably well
then that is a clearly defined hole that you can fill up. But if on the other hand your business requirements drone on about capabilities and market segments and Web 2.0 and effective customer journeys and an enhanced 21st Century user experience to the exclusion of anything concrete you could actually code from, just stop dead right there. Go and fix some bugs in a system that is being used for real. In the absence of bugs, just go down the pub.
4. Aim Low. It Is Going To Be Much Harder Than You Think
To paraphrase a Great Man(****), in software development, to be negative is to be right, 90% of the time. Bits of library code your were relying on turn out to be woeful and bug-ridden. Fully signed-off specs are completely junked and rehashed twice in the first month. Quick surgical tweaks become open-heart quintuple bypass operations. Extensively tested code drops are rolled in and immediately backed out amid a welter of ghastly, showstopping, blindingly obvious, (but somehow strangely elusive during QA) bugs. Even the report you thought you could knock off before lunch elongates into a whole week’s work.
Pessimism in this instance, as always, is your friend. Think of everything conceivable that could go wrong. Then think of everything inconceivable that couldn’t possibly go wrong. Think of the worst ways all of these incipient disasters could play out and double them. That, in a nutshell, is about as well as it can possibly pan out, and even that level of success will require a good dollop of luck. Let that rich blend of fear, cynicism, naysaying and doom-mongering (or pragmatic, scientific, evidence-based realism, as I prefer to term it) be your guide as you keep your goals simple and make your commitments as tiny and late as possible. At the highest level of Shambles-conscious maturity, commit to absolutely nothing until you know for sure that the code requested has already been written, tested and bug-fixed. I consider any promise made to a stakeholder outside these conditions to be indicative of weakness of moral fibre. An exception to this precept can be made if the Programme Director has threatened to taser you, and has the weapon visible in his hand.
5. Bite Off What You Can Chew, One Piece At A Time.
Even if you’ve dodged grandiose requirements and steadfastly resisted making foolish promises at an early stage, you’ve probably still been landed with a project that is frighteningly large. Fear not. Simply chop the thing into its component parts, as small as you can manage. Any elements which are still big, ugly, ill-defined, silly or difficult, slide off into a corner somewhere, ideally under a thick shag-pile carpet. If you can by effort of will forget about them for long enough, they might well go away. What you are left with then are the pieces which are clear, relatively straightforward to do and have some purpose. Line these up in order. If no particularly sensible priority is given to you, put the easiest ones first. Pick the top half-dozen, write them, test them and put them live. Have a customer or two use them for real. Once they’ve finished moaning about how crap the system is and you’ve fixed it to their satisfaction, repeat the exercise. Carry on until you run out of painless jobs and all that’s left is the mound of crap under the carpet.
Various scenarios are possible at this juncture but normally the pile does not now look half so intractable as it did when you started. You now have a team of people who have experience of the project and what it is meant to be doing. You can all study the remaining requirements with more educated eyes. Some of the grot may now be self-evidently pointless and thus quickly bin-able. Other chunks will now make more sense and so be amenable to being chopped up themselves into dainty, neatly codeable morsels. You can therefore extract them from under the shag-pile and bring them back into play. You may also have realised along the way that there are a couple of dozen other features that are essential but which nobody thought of at the beginning. Probably best to include these, rather than wade through miserably undefinable rubbish.
Keep plodding round these loops for a while and you will in a few months have a quite reasonable piece of kit in active use doing what the people using it genuinely want. It might not be what they said they wanted at the beginning, but then at the beginning they didn’t know their backsides from a hole in the ground, speaking frankly.
The above approximates to a lumpen D.P. Gumby version of the much vaunted Agile Approach. For all the philosophising bandied around about it, Agile is more applied common sense than science; it is simply the distillation of many gallons of bitter experience, hard earned by generations of humble software artisans. Based as it is on the accumulated sufferings of the IT peasantry, it can be well summarised by a series of artless, rustic proverbs. A journey of a thousand miles begins with a single step. Half a loaf is better than no bread. Rome wasn’t built in a day. Mighty oaks from little acorns grow. One day at a time, Sweet Jesus.
The ideal way to express this super-concentrated folk wisdom is of course through the transcendent Musical Medium of the Common People: Country and Western.
Johnny Cash, One Piece at A Time. Cash was an early advocate of agile methodologies though in the automobile industry rather than IT. As Cash notes, “One piece at a time and it didn’t cost me a dime”, indicating the marvellous budget efficiency of the iterative approach
Further atypically sunny optimism next time …
(*) If you shop around. Terms and conditions apply. Other network providers are available.
(**) Ever Ready Bike Lights of late 70s vintage.
Battery life circa 20 minutes. The slightest knock or drop of rain would bend, break or rust the contact strips and they would never work again. Clunky grey plastic lumps of super-concentrated awfulness. If you have ever wondered how it came to pass that nothing at all is now made in Britain, this is why.
(***) Excel and email. 80% of your business computing needs can be served by judicious use of these two humble software pack mules. When presented with an incipient IT Shambles, perform this Thought Experiment: rather than tip skips full of fivers into the pockets of strategic supplier-partners and coding worthlessly during an 18 month Deathmarch, could you instead get more or less the same result from a combination of:
- A word processor, a cheap’n’cheerful database or a.n. other bit of free / readily available software.
- A handful of fileservers
- Almost no coding
- A couple of competent admin people
- Some common sense
A tenner says you could.
(****) John Cooper Clarke. Clarke was talking about Salford rather than software development at the time, but the point stands.