The Extended Dream Team (I): 57 Varieties of Moron

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.

Architects

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.

Your high-level design, yesterday. You’re gonna need a bigger board.

Your high-level design, yesterday. You’re gonna need a bigger board.

 

 

 

 

 

 

 

 

 

 

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.

Customers

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.

Examples: Cake (left). Software (right). Not the same.

Examples: Cake (left). Software (right). Not the same.


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
Advertisements
This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.

17 Responses to The Extended Dream Team (I): 57 Varieties of Moron

  1. Mike Winiberg says:

    Bl**dy Brilliant – and SO TRUE!

  2. An Architect says:

    It seems that you’re not a good developer, so better start learning how to code a batch file and then you can start ranting about Architects. Here is the correction…

    @echo off
    :top
    echo Pee Po Belly Bum Drawers Bottom Burp Wee Wee Knickers Trump Winkle Widdle Boobs
    goto top

  3. Frank Lucas says:

    All I can say is, “So true, so true.” And well-written. Thanks.

  4. maxvernon says:

    Quite easily teh most refreshing thing I’ve read all day. Thank you!

  5. itshambles says:

    Thanks ! I’ve gone viral, clearly. There’s a bit of back-catalogue vitriol elsewhere here but don’t hold your breath for the next installment – frequency’s dropped back to about once a month.
    Oh – and I reckon I am already fully qualified to rant about just about anything IT-related, architects included, just on account of being an embittered middle-aged bloke with two decades of shambolic IT projects behind me.

  6. chaiguy1337 says:

    I disagree. Visual Basic is not software.

  7. Johnny Boy says:

    I never forward on links to time wasting blogs as my employer takes a very dim view of such activities. I think I may be looking for new employment shortly, after reading (and sending to lots of my favourite architects) this superb rant.

  8. Lonely Old-Style Architect says:

    As a (security) architect this gave me a good chuckle – it’s not completely undeserved!

    What our ilk *should* be doing is keeping the over-caffeinated sugar-addicts called “developers” under control, lest we end up with the old adage of “if builders built buildings the way programmers wrote programs, the first woodpecker to come along would destroy civilisation”.

    But sadly, with more and more architects (in my experience) coming up through all sorts of ranks, none of them actually with a background in development (unlike myself), you end up with people who are utterly lost the moment you take away their TOGAF, their Visio and their whiteboard.

    When you have discussions on LinkedIn architecture groups questioning whether architects actually need a background in having *done* the things they’re “architecting” (from development to systems to security) and from certain tertiary educational institutions now offer degrees in “enterprise architecture” – resulting in 22 year old newbies calling themselves EA – then you know that it’s become a bit of a circle-jerk. I feel very lonely sometimes when I seem to be the only one of my “peers” who actually can write a line of code or describe the workings of a TCP/IP network.

  9. itshambles says:

    Cheers ! There’s a lot to be said for serving an apprenticeship, in my book. I have to be honest and admit (through gritted teeth) that the architects at my current employment provider are top-drawer stand up chaps – bright, pragmatic, do actual useful work when pressed.
    Note that I shall shortly be moving on to slag off developers, testers, project managers, analysts, technical authors, receptionists, cleaners and probably even the old boy that cuts the grass outside the office. No-one escapes my endless supply of bile, laboured sarcasm and recycled jokes.
    I notice nobody’s waded in to defend Customers. Funny, that …

  10. Funny it echoes what two very, very clever sales mangers have told me on two separate but, incidentally, very, very drunken occasions. Apologies to Mr Kelly and Mr Lagan.

    “The customer is mad, misguided, malign and plain bloody malevolent but he is signing those checks so he is right. Do exactly what he says and don’t worry lads cause I’ll charge him double to fix it.”

    Funny they are both retired and multi-millionaires. I on the other hand am not.

    Sebastian <– Developers of the world unite all you have to lose are your bits

  11. er guiri de lamiga de la prima esa says:

    Well written: funny, with a ring of bitter truth. Too bad that truth is the first victim in a war, and by Jove, we are in a war, an entrenched battle, going all agile over the top. In 14 days you can tell me what went wrong.

  12. itshambles says:

    Ta! Bitter ? Maybe so. I prefer to think of myself as weary and despairing. But on the bright side, I’ve never myself met a likeable, avuncular sales manager with wisdom and insight but I am heartened to know they exist.

  13. Pingback: Estimation, Part 1: I Have Seen The Future, But It Was All Wrong | IT Shambles

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s