Getting to "yes" in a world of "no"…

What does “Agile” mean?

To most people, “Agile” is – like “Lean”, “Cloud”, “SCRUM”, and “Virtual” – one of those modern software development buzzwords that sounds vaguely scientific and valuable, while probably meaning almost nothing.

Yet a vast consulting and training industry has sprung up on the back of Agile. People take courses in how to be Scrum Masters, how to Unblock, to build self-managing teams and to design Epics. They ingest the Seventeen (the precise number varies) Golden Rules Of Effective Stand-up Meetings, and Groom and Iterate cheerfully through their Backlogs to increase their Story Point Velocity.

(Don’t worry if the above sounds to you like an explosion in a buzzword factory, because that’s basically what it is.)

Moreover, software companies that commit their workforces to Agile (typically by getting them to stand on the edge of a cliff overlooking the Bay of Agility, and ordering them to all jump off at the same time) seem to get praised by allegedly smart investors, while non-Agile companies get slated as old-fashioned, waterfall-obsessed fossils.

Is this whole [ Agile vs Dinosaur ] dichotomy fair? Or accurate? Or helpful?

But to me, the most-ducked question of all is this: what, in any useful sense, does “Agile” actually mean? Few Agile proponents seem happy to answer this without lapsing into the whole avalanche of secondary buzzwords typical of the second paragraph.

Even though it would be easy to dismiss Agile as no more than a way of collecting buzzwords like baseball cards, it turns out that there is a core of useful truth at its heart. In fact, you may be surprised to learn that this revolves about what it means to be a professional modern software developer.

You see, during the 20th Century, programming grew up in smart-guy (yes, usually male) ghettos within large organizations: it was an anti-social, isolated, unintegrated pastime sold as a value-adding professional intellectual skill.

On top of that, a long-standing structural problem within the whole industry has been that a traditional software developer isn’t someone you would like to show to your sister, let alone to a customer. And for a very long time, many programmers have played up to this self-indulgent stereotype: the beards, the sandals, the obscure terminology and bad acronymic puns when naming things. Yecccch. (Or do I mean ‘YACC’?)

At their most programmery, these sad creatures liked their ghettos, and fought long and hard to keep their comfy development world just that way. They far preferred to remain aloof and remote from sales, marketing, finance, HR… in fact, to stay apart from just about everything else (even from hardware, truth be told). Hence software’s guilty little secret is that it has been a profession only lightly integrated within broader organizations.

But business has changed – really changed. Modern software professionals now need to be able to present their work, and to negotiate (and iterate) requirements with customers in a more parallel, self-determining way. Software design is becoming just as much a social medium as an exercise in system optimization. As a result, the old, stay-out-of-the-loop approach to building software just doesn’t cut it any more.

So here’s the central paradox (or, indeed, the future challenge): though programming is an industry still socially dominated by code ghettos, modern business demands that the people in it need “social smarts” just as much as technical smarts, even though they only typically get trained in the latter. And their day-to-day tools of choice are usually technical, too.

But… where does a modern software professional go to get trained in social smarts? The answer is: they don’t. But the nearest they currently get to this is a kind of pragmatic social Boot Camp – by working within an Agile team. Agile practices, though dogmatic and an awkward fit for many tasks, often force programmers to confront and surmount their social limitations: which is usually a good thing.

As a result, what “Agile” means (particularly on someone’s CV) is that they have been ‘blooded’ into the difficult arena of modern software development – that they have (or should have) at least some of the combination of both technical skills and social skills now needed to call themselves a ‘proper programmer’.

What, then, is going on with this whole ‘Agile Movement’? Personally, I believe that what a company is doing by embracing Agile is forcing its workforce to enter into a transition from antisocial 20th century software development into far more social 21st century software development. That is, to move from the old world of serial, top-down, micro-managed, manager-led development to the new world of parallel, bottom-up, team-managed, customer-led development.

(Though contrary to what many claim, this doesn’t mean that the code produced by Agile organizations is any better. In many ways, the incrementalism necessitated by Agile goes against proper software engineering and proper software architecture, which in practice can often yield weaknesses and fragilities as profound as those engendered by traditional software development practice.)

Really, to make a good practical contribution to the majority of the projects I see happening these days, you need to have the skills both of traditional software engineering and of contemporary Agile practices. (It’s not an either-or choice, you almost always need the two simultaneously.)

Would I hire someone with Agile on their resume? Why, yes I would. But I’d always interview them and ask myself: regardless of how well they can programme, would I be comfortable with putting them in front of customers? Because that, increasingly, is where they are going to be over the coming decades, whether you like it or not.

Finally… in time, it seems almost certain that Agile’s constellation of idiosyncratic terminology will be lambasted as a domain-specific ‘Buzzword Bingo’ of only historic value. But I would argue that this will only be true because its core values of what it means to be a modern software professional will have been thoroughly absorbed into the development mainstream. Chillingly, we’ll all be Agile then. Who’d have thought it, eh?

I’ve just spent four hours trying to install Emscripten; firstly under Windows, and then under Linux.

I failed. Miserably.

From my experience, I’d say that the installation instructions are currently (a) fragmented, (b) out of date, (c) inconsistent, and (d) just plain wrong. Very frustrating. It’s a long time since I’ve been presented with so many absolutely inscrutable error messages in a row, and it’s going to take a large effort of will to put myself back through that again.

Also, my opinion is that fastcomp should never have stayed in a side-branch for so long. It’s crushingly obvious that fastcomp is an absolutely necessary part of the whole mix, and so the current instructions for merging the side-branch tools into a working build are just maddening and dis-spiriting for someone coming in from cold.

Emscripten people: you have a thing of wonder and usefulness, yet your getting-started documentation can only be alienating developers such as myself from getting involved. Please turn this around, and put step-by-step Linux installation instructions for 3.4.1 and/or 3.5 on the web somewhere that actually work.

What is so unreasonable about that? *sigh*

I had a nice coffee today with an old friend from my schooldays who sold his decent-sized company not so long ago: it didn’t take long for the conversation to turn to business angels and pitch meetings, something which we both have had a lot of exposure to (though largely on opposite sides of the same wonky-legged table).

On the one hand, in order for startups to get past angel gatekeepers to pitch, they have to kid both themselves and others that in 3-5 years’ time they will multiply an given investor’s stake by at least 10x: this is the modern pitch template, the model that startups are required to replicate in order to be considered “credible” (But of course nobody has that kind of control over the future, however smart you are).

Yet on the other hand, my experience of rapidly growing companies is that they are structured in an open way to allow external serendipity to play a very significant (if not actually a near-majority) part. In fact, I suspect the real growth of such companies would best be charted in a bar graph with “Years” along the bottom and “Lucky Breaks” up the side. (Note that I don’t believe anyone has ever put such a graph up in front of potential investors, except perhaps with some kind of satirical point in mind.)

What struck me most forcefully was the sharp contrast between these two startup “models” – between the PowerPointy pretence of control and the (actual) near-total absence of control. The whole startup discourse has become a slave to the MBA-ified cult of the jut-jawed CEO hero making dramatic bets against the market’s groupthink, all the while the realpolitik of business has grown more diffuse and collaborative, where opportunities more often arrive as partnership outcomes than as snatched moments of solo market brio.

I don’t know: as I’m typing this, I’m feeling the hopelessness of the whole situation – as though angel investors and their groups have, by steering the ‘model’ to such foolish extremes, become 10x more of a hindrance than a genuine help to the whole sector. Add in the triple-whammy cargo cults of the ‘killer deck’, ‘elevator pitch’, and ‘executive summary’, and you have a pervasively dysfunctional setup to deal with.

Right now, I have this huge urge to stand in front of a room of business angels and just, I don’t know, tell them the goddamn truth. You know, that business is hard, arbitrary, strange, but collaborative; that what genuinely differentiates proper startups from, say, window cleaners is they take a certain combination of ambition, drive and scalability and aim it all at a fat (but wobbly) market; and that if I could tell the future as well as angels apparently need me to, I’d be betting on Lucky Boy in the 2.30 at Haydock Park, not standing in front of them.

But most importantly I want to tell them that it is their shared model that is killing startups: that if they had the guts to invest in startups without having them go through that stupid ritual of pretending to have sufficient omniscience, omnipotence, and precognition to guarantee insanely good ROI, then maybe they’d get the kind of returns on their investment they wanted.

Really, do I honestly think there’s even a 1% chance many will stop punting their miserable pin-money stakes into social me2dia shutdowns (i.e. the opposite of startups) anytime soon? No, of course not, not a hope. But that’s the view I get from here, make of it all what you will.

It’s a while since I made a proper web-log blog post, so here are some interesting JavaScript postcards from the edge that I found while trawling the web. Enjoy!

* Best link there is: Essential JavaScript Design Patterns by Addy Osmani – great little ebook (and free!)

* Peter Michaux’s Early and Late Mixins

* What is the length of a JavaScript array?

* JavaScript declaration hoisting – great for job interview tests, terrible for real code

* It turns out that you the JavaScript delete operator can never delete objects (only properties of objects). Just so you know!

* How to have a JavaScript function return undefined.

* A neat JavaScript chess programme called GarboChess. I like it!

I recently wrote (and indeed published on Amazon) a nicely interactive chess ebook (Chess Superminiatures, based around more than a hundred real-life chess games all under ten moves long). As a result, my exposure to all things ebook-related and ebook-business-model-related has spiked sharply in the last month or so.

But when it comes to VAT and ebooks, even I didn’t see this one coming.

It’s like this. The basic business model for ebook publishing is as an Agency arrangement, so if you buy a Dorling Kindersley ebook on Amazon, you’re not buying it from Amazon, you’re actually buying it from Dorling Kindersley with Amazon ‘merely’ acting as an Agent. (Yes, even though Amazon does the hosting, selling, customer transaction, billing and money collection, and then gets to sit on the money for 60 or so days before passing it on to DK.)

All the same, at this point any underlying business model differences are merely semantic as far as a customer is concerned: if you’re buying an ebook, you don’t particularly care whether it was Amazon or DK that sold it to you. You know that it ultimately came from DK, the rest is just meh.

…except if you want a VAT invoice for your purchase. Because unlike normal books, the price of ebooks (potentially) contains a VAT component (i.e. if the seller is VAT registered). Did you know that? But… how would you get a VAT invoice for an ebook?

This is the point where it gets fuzzy and legalistic.

Because it is acting as an Agency, Amazon itself doesn’t charge VAT on the sale, because the transaction is between the customer and the ultimate publisher. So whether or not there is VAT on the transaction depends on whether the ultimate publisher is VAT registered, and that is not actually made clear on the Kindle product screen.

But all the same, you would have thought that an Amazon-mediated transaction between a customer and a VAT-registered publisher would necessarily generate a dated VAT invoice of some sort, as just about every other VAT-rated transaction in the EU is required to do, right?

Wrong! Amazon sidesteps this entire issue by sneakily insisting in its Terms & Conditions that Kindle content is only ever for “personal use”. With this single stroke, they (seem to) remove the need for VAT invoices, because someone buying a book for “personal use” would not have any explicit need for a VAT invoice, because they would – as an individual – be unable to claim back VAT.

So that’s the end of that… or is it? Frankly, if I was an EU commissioner tasked with dealing with Amazon, I would be spluttering with fury into my latte every time this topic came up, because Amazon plainly sells a whole host of business-oriented content for Kindle readers, and the wave of ebook titles swells ever higher each year.

This “for personal use only” in the T’s and C’s is without any doubt nothing more than a gigantic hack: as I wrote elsewhere a few days ago, the person who first devised this trick is probably still chortling into their hand years later. In fact, it’s such an epic business model hack that I think it genuinely deserves its own Wikipedia page – give credit where credit’s due!

So, to be truthful, the line should say something like “possibly includes VAT if the ebook publisher is VAT registered (irrespective of Amazon’s own VAT accounting), not that you can claim it back because only personal use of Kindle content is allowed within Amazon’s current T&Cs”.

Way back in 2002 or so, I devised the idea of “gamification”, a clunky (but useful) way of proposing that electronics devices of all sorts would be vastly improved by taking on board the lessons games companies had had to learn. My position was simply that the games industry was the ‘cradle’ for the major technology waves that were just about to break, and that tech people needed to get their heads around that.

The people at Apple certainly did: in terms of how I personally describe gamification, I’d say that the iPhone, the iPad, the iTunes Store and the App Store are prime examples – near-frictionless interfaces coupled with a games-industry-informed platform-centric way of doing business. And that certainly has done the company nothing but good.

Websites, too, were something that concerned me greatly back then: when I looked (and still look) at websites, the thing I look for more than anything else is a kind of ‘authorial voice’, an online corporate presence in a rather more literal sense than the phrase usually connotes. You also find this in packaging copy and TV voice scripting (e.g. Innocent Smoothies have a great ‘voice’, Shakeaway usually pitches it right, More Than has become pretty good, Orange used to nail it but has lost its way, Apple comes and goes, Coca Cola sucks terrifically, Macdonalds is even worse these days, etc).

In retrospect, what subtly linked my twin obsessions from back then was what I now call the notion of psychological distance – for if authorial voice is the process of ‘humanizing’ a company to the point that it can actually talk to you in a language that you can almost accept as human, then gamification is very much the process of using technology to reduce the psychological distance between you and it – bringing you emotionally closer to it.

The example I like to give to show the limits of gamification is the whole idea of a government tax website: though it would make sense to tune users’ flow through the tax website, the idea of using gamification techniques to bring the user psychologically closer (and somehow more emotionally aligned) with The Taxman would seem somehow alien to a lot of people.

But even though this seems like a kind of counterexample to the whole gamification-is-universally-good gospel, maybe – just maybe – you could make a positive difference here. All the same, you’d have to start your design process from a radically different corner to normal… that of psychology and empathy.

The most basic ‘empathy hack’ would be to add a changing sidebar showing simple top-line statistics about what your tax money does for people – education, healthcare, etc. Tax shouldn’t be presented in a stark, oppositional way, when it is actually the backbone of how a civilized society functions. Tax is how we get money fairly from the people who make it to the people who need it – and illness or changing personal circumstances can rapidly alter which side of that whole equation you happen to be sitting on.

My point here is that by reducing the empathic distance between the website user and the website owner as a first step, we are already oiling the conceptual wheels in a very direct way. By adding this kind of touch, we’re giving The Taxman a believable human voice (rather than a cartoon bowler hat, *sigh*). Only then can we start to think about anything so fancy as gamifying the interface – in sales terms, you need to answer the “who cares?” question long before you try to close the deal.

Beyond that, it’s an open question about what the tax website people would need to do: but my larger point is that gamification is hugely dependent on a collaborational mindset having first been invoked or engineered. Without a proper appreciation of psychology (and how things like authorial voice can to a large degree help), gamification isn’t really a lot of use.

I think it was Gartners who claim that 85% of current gamification projects are likely to fail: my point here is that without actively trying to reduce the empathic distance first, many such projects would never have a chance of working at all.

More generally, in these days of customer-centred design, I’d contend that interface design is fast becoming an exercise more in psychology than in programming. But I’m not sure if even a single current CompSci course has this as a design precept, not even the computer games courses. The world is changing fast, that’s for sure…

Infographic suckage…

I’m sorry, but even for the purposes of satire I couldn’t bring myself to click on the [add patronizing rows of little jelly-baby men] button. Really, nothing highlights the suckage, banality, and information underloadedness of most infographics better than infographics themselves…



Get every new post delivered to your Inbox.

Join 407 other followers