There has been some droning at moderate length in earlier posts (especially here) on the topic of balloxing things up by getting the most gormless eejits you can find to take a crack at writing software. I may also at times have evinced a less than complete respect for the Leadership Team and their profound contribution to project success. See … well, pretty much any previous missive. Picking out the denizens of the cubicle farm on the one hand and the pastel-shaded executive breakout area on the other was not wrong. Hopeless developers have a special ability to wreak havoc on a job, as at the other end of the hierarchical organogramme do hopeless senior managers. But taking stock now, I feel the focus has been too narrow and has left gaps in my analysis. I have failed to take a holistic, 360 degree, front to back, soup to nuts view of the shambolic IT space. There are in fact all manner of different sorts of pillocks who can completely screw things up. Let us start at the top, with those who destroy time, money and hope as a matter of routine.
Toddlers. Precocious toddlers on whizz, with a felt tip in one hand and the other covered in chocolate sauce. They like drawing pictures, they create mountains of mess, they never tidy up after themselves, they change their mind every twenty minutes and despite believing six fundamentally impossible and mutually exclusive things before breakfast, any and all opinions are held with a fervour that would make Islamic Jihad blush.
The Architect’s natural habitat is the whiteboard. There will be boxes, clouds, squiggles, arrows and lines, all annotated with cryptic, acronym-rich haikus. When a dozen whiteboards have been filled with abstract expressionist scrawl, their collected wisdom will be distilled into Visio. The dreaded Visio diagram is the whiteboard but neutron-star-dense, with microscopic nano-fonts and a limitless selection of polygons and clip-art. This then is your design, and you have to build it. Each tiny coloured blob represents a new piece of kit, a new interface, a new programming language and an entirely new engineering paradigm(*) that no-one has ever used before. New, new, shiny shiny new – everything must be brand spanking new in Architect World. But it has to be absolutely pristine. As soon as the cellophane’s off the new toy and it is in active use, it becomes boring. Outmoded. Passé. Superseded. Legacy. And then it’s time for a new Visio diagram and a vital strategic systems refresh programme to implement it. If your architects are in the driving seat, this programme normally kicks off about two months before you finish making the thing it’s due to sweep into the dustbin of history.
There are a few flavours of architect – Infrastructure ones, Solution ones, Enterprise ones. The basic spec is more or less the same, but the level of abstraction goes up as utility goes down and the tenuous connection to objective reality loosens. Off at the far end of the continuum you’re into pure baloney wibble wibble hatstand fantasy land. Brevity is considered the cardinal sin in the Enterprise Space, to boot. The vast reams of documentation produced by Enterprise Architects can be daunting. There will be virtual shelves full of frameworks, taxonomies, data models, roadmaps and methodologies. 97.6% of the time, if you can steel yourself to wade through the pages of appalling prose and impenetrable verbiage, it amounts to using a truck load of high-falutin’ polysyllables to state the bleeding obvious.
To taunt you, just occasionally the Fates will throw an architect your way who actually does proper work. He will examine the mess of jerry-built pipework that is your existing system, ruminate on what is required and prescribe a bit of surgical spannering to meet the need. Unbolt this bit, twist that one, cut out a couple of others, tweak a config file here and write a couple of chunks of Delphi there. Bob’s your uncle. Amazingly, having produced a workable blueprint he will leave it alone, rather than constantly jiggering about with it such that it’s radically different to what you started with by the time you’re half way through coding. For once you won’t have to chuck away weeks of work and start again from scratch.
The other 99 times out of a 100 you’ll be landed with the usual hyperactive neophilic ankle-biter. Best bet to keep him onside is flattery and indulgence. Buy him a wall-filling whiteboard and a couple of crates of markers. Shell out a few extra quid for some really whizzy colours: metallic gold, electric blue, imperial purple. Set him off to dream up the ultimate palladium-coated, tungsten-tipped solution. Give him as long as he wants – you’ll hold off the Suits with a few disposable tactical hacks while he drafts a system fit for the 22nd century. Obviously, it’s going to take a few iterations. You can’t cut corners on the path to perfection. Each iteration will need review with his peers, and you can contribute to that too. You’ll be supportive, but you’ll want to make sure all the bases are covered. Have we considered Separate Deployability ? The Cloud ? Service Orientation ? TOGAF ? And, naturally, The Zachman Framework ? Each iteration, bring just one more slab of received wisdom to the table. Don’t think twice about the overlaps, contradictions and endless backtracking. It’s All Good. Meanwhile, somewhere below the clouds, you have just about finished the rather long series of disposable tactical hacks that’ll serve well enough for the next few years. Time it right, and those grubby but practical botches will be live just before the budget runs out, but with the glittering super-utopian design a good few weeks away from completion, in all its Zachman-compliant glory.
Ach. Shame. Next time, maybe.
Whoever coined the phrase “The Customer Is Always Right” had clearly never met any. Or maybe he was working for the Pope, who apparently is infallible. Most customers do not have a clue. They are not sure what they want themselves and certainly can’t articulate their desires, but despite that are sure that it has to be ready by the end of next month and should cost no more than ten grand. Or if you’ve already told them it’ll be ready next month and will cost ten grand, then it should cost five grand and be ready next week, and you should have also coded up all the other bits they’ve not told you about yet but which are absolutely vital. Whatever you offer, it’s always Too Much, Too Little, Too Late.
Johnny and Deniece exploring the classical Customer-Supplier dialectic in smooth R&B style, 1978. The production on that album is amazing.
Buying software is not like buying banana muffins at the Co-op. Software is not cake. Your average procurer of muffins is fully aware of the acceptance criteria for baked goods. They could probably knock up perfectly decent sticky buns themselves, but have weighed up considerations of quality, time, effort, cost, convenience and washing-up in a logical fashion and decided that four for a quid is a bloody good deal. Software ain’t like that. Most commissioners of bespoke software couldn’t write a batch file, not even one that just fills the screen with rude words (**). They don’t know the first thing about databases, compilers, algorithms, conditional logic or Boolean algebra. You could try and thrash out why what they have asked for is difficult / impossible / labour-intensive / pointless or why they might need to spend a chunk of time defining what they need more accurately and intelligibly. But to be honest you might as well start explaining the Copenhagen interpretation of quantum mechanics to them, in Sanskrit.
It is a completely asymmetric relationship. You, the seller, understand and can do software development. The buyer can’t understand or do anything. This should be to your advantage – given their ineptitude, you ought to be able to dictate terms and get paid best brass, even if all they want is a batch file that fills the screen with rude words (**, again). They should defer to your superior knowledge and accept your technocratic wisdom as gospel. Perhaps back in the mid 60s, when computing was mysterious and exclusive and time had to be booked in hours on the English Electric mainframe at Kidsgrove, this would have been so. Half a century later computers are ubiquitous and unremarkable. We all now have the processing power of several dozen first-wave mainframes sat in our pockets. What do we do with this computational bonanza ? Why, we post picture of cats looking stupid to our friends and text our other halves to say drinkin up now bak l8r luv u. Familiarity breeds contempt. A few tweets, a YouTube upload of a mate falling off a bar stool, a couple of snaps of moggys in hats onto Facebook and everyone’s an expert. But as the using of computers gets easier, faster and more impressive each year, writing code stubbornly remains as arduous as it always has been. Maybe harder in fact, as the expectations are so much higher – yeah, fine, it works I suppose, but we need it in 3D with voice control for all the major Chinese dialects.
The problem you have here is one of economics – software development almost always runs within a closed market. In your bog-standard grim IT shambles there is precisely one buyer (the customer), one seller (you) and one product (whatever rubbish you’re attempting to knock together this time), and you are all stuck with each other. In the open and free market for confectionary, the would-be muffin consumer could opt instead for Jaffa Cakes on markdown at 75p, or they could just sod off to Tesco with no hard feelings. In the pre-capitalist world of IT projects, the relationships are feudal, and the customer is Lord of the Manor. You and everyone else are the serfs, ploughing through fields of subroutines. Half a century ago when computers were exotic and inscrutable, we had the prestige of the medieval clergy. At that point we still retained some mystique and authority. Only we, with our magical incantations inscribed on the Holy (holey ?) Punched Cards could bend the capricious collection of circuit boards to do our bidding. 50 years on, we’ve been reduced to villainous peasantry, we rely on the tenants of the Big House for food, and so of course they can call every shot as they nibble on roast pheasant and marzipan.
Ergo, we are at the whim of the autocratic customer. He knows exactly two fifths of sod all about software development but he’s got the cheque book so he’s in charge. This works about as well as science and technology ever did under feudalism. Recall for example the great successes of alchemists in transforming lead into gold, or the marvellous advances in life-expectancy during the middle ages brought about by blood-letting, leeches and cupping. So The Customer wants it live this week. It’s still in bits but we release it, half-finished warty bugs and all, and another predictable preventable disaster ensues. He next decides that email is old skool; the system should be getting hip to Social Networking. All other work is dropped and all hands are on Twitter for the next few weeks. Until his next lightning bolt of inspiration, which turns out to be an all-consuming obsession with security. The Twitter interface is swiftly binned and the next six months are spent encrypting, obfuscating and password controlling the bejasus out of everything.
And so it goes on. The next logical, indeed historically inevitable, step is a revolt of the downtrodden masses. If you ever feel like collectivising your workplace and sticking the head of your Senior Client-side Stakeholder on the end of a pitchfork, gimme a call.
(*) Paradigm. Nope. Still no idea what it means. But best to nod sagely when architects talk about them at work. A paradigm as any fule kno is a Good Thing, especially if it’s a New one.
(**) For reference, I can write a batch file that just fills the screen with rude words, viz::top echo off echo Pee Po Belly Bum Drawers Bottom Burp Wee Wee Knickers Trump Winkle Widdle Boobs goto top