The Superhero Developer

The Agile Angel was reading an excellent blog the other day

http://blogs.atlassian.com/developer/2009/06/pair_programming_is_kryptonite.html

about the virtues of pair programming. Its a good piece of writing. However, somewhat predictably, several of those who commented on it went to some lengths to describe why pair programming was not suitable for them and other ‘Superhero’ developers. (yes Mr. Perez, she’s aiming this at you)

What a load of pish.

By way of a slight biographical diversion, pair programming was the main reason for the Angel’s Agile epiphany. She can still recall the day when, quite unexpectedly, a colleague furnished her with a copy of Extreme Programming Explained (1st Edition). As she turned the pages she began to salivate at the potential contained within this little book. It was as if all her doubts had been confirmed. It validated her uneasiness about the way software was currently being built and offerer her exciting strategies for change which resonated immediately and dramatically.

She devoured the text. And immediately re-read it.

What struck her most amongst all the suggested practices was Pair Programming. As she read about it suddenly it seemed so obvious, so logical. Why hadn’t she thought about it before?* This was truly radical. This could change the face of software development.

She could now see a healthy, life-affirming way to write code. She would no longer have to spend lonely hour after hour scratching her head, doubting her decisions, staring into space looking for answers. Instead this would be replaced by a truly intellectual dialogue between fellow professionals who would strive together to create wonderful software.

Looking around her office at the assembled, unwashed, geeks-for-a-living she could see there might be a few problems adopting this technique, but she hoped that in time when this practice was widely accepted that it would gradually change the nature of the stereotypical developer for the better. The ultra-geeks with their lack of personal skills and often similar lack of personal hygiene would give way to a new breed of software professionals who were erudite, charming, thoughtful and wise. Something like the gentlemen scholars of the Victorian age, she fancied.

She sat back in her chair and dreamed her dreams.

Unfortunately reality bit and of all the practices that XP espoused it seems that Pair Programming was the one that was destined to be the most contentious. It did not get universally accepted and still to this day it is the one practice that she finds hardest to introduce to any team. So called Super Heroes actually seem to despise it and yet it is the very technique designed to get the best out of them and their team.

Alas therefore her dreams of software erudition have not yet come to pass and every day her interest in development diminishes and contempt for her profession grows. But still she hopes, and waits. And as she waits so she feels she must combat the nonsense of the Superhero developer head-on whenever she sees it, lest Pair Programming shrivel and die.

To begin with the Angel would like to suggest a few characteristics that the so-called Superhero programmers tends to possess.

They consider themselves superior to their colleagues.

They tend to suffer from programming eccentricities such as needing to work in the middle of the night.

They are almost always their own judge of competence.

They think working with other no-super heroes is detrimental to their performance.

They overvalue their contribution in real terms.

And thus they dislike Pair Programming.

These Superheroes are very dangerous in the Angel’s opinion and notice how similar they are to the Twonk!

They consider themselves superior to their co-workers and in fact the Angel does not disagree that this might be the case but it is almost always meaningless. There are many, many Twonks in the workplace. Twonks against whom you may well compare very favourably. But this does not make you a Superhero. She reminds these would be caped crusaders that they need to look at the the sample-size from which they came. Excelling in comparison to Twonks means only that you are probably not a Twonk and even then there is no guarantee. Anyone can be a big fish when the pond is small or shallow enough.

More importantly ‘Superhero’ programmer is not a title you can bestow on yourself. It must come from the judgement of your betters. As she noted previously the adulation of Twonks is meaningless. They are not in a position, due to their own limitations, to know whether you truly are a superstar. You need people who are better than you to correctly assess whether you might belong among them and your organisation needs to be doing things considerably better than the competition for your achievements to mean anything.

If there is one characteristic that the Angel thinks all real Superheroes possess (especially the kind with capes) it is that they exist to help others. Therefore to dislike working with and helping your less gifted colleagues is a sure indication you are not among the Superhero classes. She agrees you could be talented but because you are not putting your powers at the disposal of the weak, you are in fact a Super Villain! You would rather rule supreme than lend others a helping hand.

And what of your so called Heroic contribution anyway? The Angel would like to point out the somewhat obvious fact that the vast majority of all software development is nothing new. She reckons that more then 99% of all new code written today is simply an instance of something that’s been done a thousand times before. There are limited opportunities for super-powered-code so how much contribution do they really think they are making? What’s the point of having the strength of a thousand men if all you are doing is carrying the shopping?

Software is actually, to paraphrase many poker writers, primarily a game of mistakes. What most companies need is not super heroic code (how many companies are really breaking the boundaries of software development?) but rather simple, straightforward, error free produce. It matters very little whether the super hero produces his** code with few errors if everyone else is introducing them by the dozen. Pair Programming helps eliminate defects. It is a safety guard and a very effective form of review. If you are a Super Hero then surely you are at your most effective when preventing others from bringing harm to codebase?

And finally the Angel needs to point out that even if the so-called Superhero is talented and can produce pretty impressive code (and lets face it it would have to be super humanely good wouldn’t it), unless they are prepared to embrace things like Pair Programming then they are overrating their contribution and missing the point of commercial software development because very few companies can get by on the amount of work a few Super Heroes can produce. Similarly, finding an army of such caped crusaders is a luxury most cannot afford. Therefore companies are always going to employ many more ‘normies’ than heroes. If these Super Heroes really understood commerce then they would quickly realise that the most important contribution they can make it to teach. Having one or two heroes may boost the team a little, but having a whole team of people learning from the Hero leads to far, far greater gains. Who knows, maybe even the creation of more Superheroes.

The Angel can think of few more effective ways to teach and to generate knowledge than Pair Programming. If you really are a Super Hero then pairing should be at the core of your beliefs. If it isn’t you are surely a Super Villain (or just a common criminal) as your only concern is to keep power for yourself.

She knows there are programmers who are real Superheroes out there because she has been lucky enough to pair with some. But they would be too humble to say so of course..

Peace.

*Its interesting to note that the very best ideas usually seem obvious with hindsight.

**And note how few self-proclaimed super heroes are women

Less Unit Testing Is Simply Bad Manners

The Agile Angel has come across a great many developers who hold strong opinions about testing. When to do it, how much to do, what should be tested, whether to mock or stub, ya-dee-ya-dee-ya. Even some of the most Agile fellows have tried to persuade her from time to time that perhaps they should do a little less unit testing.

Unfortunately most of these arguments are spurious and more often than not a plain waste of time.

The Angel would like to re-iterate some important facts about testing.

Fact: It is better to do too much than too little.

Instead of wasting your time debating about whether this or that unit test is worthwhile or if an acceptance test deserves automating, the Angel suggests you JFDI.

On numerous occasions she has heard a pair of developers argue about whether a unit test is truly necessary or not. In the time it took them to debate the point they could have just written the test. Stop wasting everyone’s time and code up the test. How far wrong can you go?

She suggests a thought experiment. Suppose for a given method you knew in advance the correct number of tests needed to provide optimal coverage. In this case you would not debate the point you would simply write the tests (you would do that wouldn’t you?). In the real world you cannot be sure where this optimal point is unless you are psychic. So, is it better to fall short or overshoot? What if the last optimal test is the one that detects the most serious defect? If you undershoot you run the risk of causing someone a problem.

And if you overshoot what happens? You spend a few extra minutes on testing but feel much better about your chances of not-being-a-twonk. A much better result.

Fact: You are not as good as you think you are.*

Too many developers overestimate their ability. In fact it is not just developers, human beings in general suffer from this problem. The Angel would like to remind all developers that humility is a powerful ally and the sign of a great professional. Assuming that you will make mistakes will lead you to conclude that better and more thorough testing are essential. She has only come across one team in nearly twenty years that held themselves down to a ‘virtually defect free’ output for any length of time.

Fact: Not testing is plain rude; defects are dirty.

The Angel can tell you with absolute certainty that the cost of a defect rises in a non-linear fashion the later in the process it is detected. There are sound, well understood economic reasons for testing early and often. But there is a much better reason for hiking up your unit tests. Good manners.

Passing on defects is rude. Its ignorant, selfish and unprofessional. The Angel is constantly irritated by the blindness of developers in understanding that if they themselves do not catch a defect then someone else has to. They are leaving a mess for someone else to clean up. You wouldn’t go to a friend’s dinner party and then stub out your cigarettes on the floor (she hopes), so don’t touch the codebase without ensuring you’ve tested your work. If in doubt, add more tests.

The Angel has, on occasion, performed the Product Owner role. This involves, amongst many things, reviewing and prioritising defects into her backlog. She can tell you that this is as onerous as picking up dog shit... from somebody else’s dog! She has to waste time prioritising, testers have to waste time filling in defect reports, Scrum Masters have to waste time discussing, chasing and scheduling and most importantly it is often someone other poor developer who has to clean up the mess as it can be difficult to trace a defect back to its originator. Its a pain, its costly and its a waste.

Don’t be rude.

Thorough unit testing is the software equivalent of having exceptionally good manners. She suggests we all behave like Gentlemen**.

* If you think you are, get a second opinion.

** or Ladies.

The Anatomy Of A Twonk

The Agile Angel (TAA) loves acronyms. She works in software FFS and if you don’t appreciate a good TLA in that game then you’re pretty well sunk.

So, she’d like to introduce you to a personal favourite. The TWONK.

Typical Worker Of Nominal Kompetence*

(ok, so the spelling is not perfect, but its such a good word she couldn’t resist).

Twonks are the rank-and-file of software development. The mediocre majority of key-pushers who make up the numbers in most organisations. Twonks exist in other industries certainly, but she has observed that software development seems to be rich environment for them to thrive.

Twonks are employees** who are not especially effective, not particularly knowledgeable, don’t really add much value but are blissfully unaware of their own limitations. Their employers also seem to fail to recognise these shortcomings. They’re suffering from the universal obsession that you can improve things by increasing the number of Twonks you employ***. She often wonders why they seem oblivious to the fact that they are actually worsening the Non-Twonk-To-Twonk ratio (the NT3 ratio).****

Understanding Twonks is extremely important to the Agile Angel. For her, effective Twonk management is one of the keys to successful software. In fact she’s quite surprised there isn’t more literature on the subject. She is considering writing a blog on TTT (Total Twonk Management).

Twonks will represent the the bulk of the people working on your software product and yet they will contribute far less proportionally than their non-twonky counterparts. In many cases she is certain that Twonks are outright detrimental and represent a significant and unnecessary overhead. She has fantasised about how productive a team might be if all Twonks were simply eliminated. What she is very certain of and has witnessed on many occasions is that if great care is not taken with how Twonks are deployed and managed then projects (especially Agile ones) will most likely fail. Good Scrum Masters (the rare, non-twonky ones) know this all too well and will usually take very careful measures to ensure they manage their NT3 ratios and to neutralise the damage Twonks might otherwise do.

Not all Twonks are bad however. A very rare breed of Twonk, the Self-Aware Twonk (SAT) can actually be quite useful. Without them and their fundamental grasp of their own limitations the non-twonks would have a lot more of the boring stuff to do. Many SATs make good Scrum Masters BTW.

Anyway, this is not an exhaustive definition but here’s The Agile Angel’s mini-guide to identifying common characteristics of a Twonk.

• Twonks don’t think they are Twonks. They suffer from twonk-blindness. (this is perhaps their biggest weakness)
• Twonks tend to assume almost everyone else is a Twonk.
• Twonks can exist at any level in an organisation but tend to either gravitate quickly up or stay low to the ground. Put it another way, if you’re not a Twonk it means you probably work for one and also have a few who work for you. Note: this can still be true if you are a Twonk.
• Twonks overrate their own skills.
• Twonks undervalue everyone else’s skills.
• Twonks account for the majority of all software professionals.
• Twonks think software is a profession.
• Due to twonk-blindness, Twonks typically fail to identify and often prefer other Twonks. This may account for the high numbers of Twonks who are able to climb the corporate ladder.
• Twonks claim to dislike meetings but always attend them (and are often noisy contributors).
• Twonks often claim to be experts.
• Twonks are rarely held directly accountable but consider themselves decision makers.
• Twonks don’t read much.
• Twonks claim to know a lot, and share it.
• Twonks don’t like having their opinions questioned.
• Twonks question everyone else’s opinions.
• Twonks are keen to teach.
• Twonks dislike learning.
• Twonks find nothing strange in preferring apples to oranges, oranges to pears and pears to apples. This is particularly true of Management Twonks.
• Twonks think its important for you to listen.
• Twonks don’t listen.
• Programmer Twonks think they know a lot about programming.
• Programmer Twonks tend to work with and specialise in one language. The more popular the language the more likely the programmer is a Twonk.
• Programmer Twonks don’t like unit testing, scripting, databases, UIs or anything else that is actually useful.
• Programmer Twonks are a source of defects.
• Programmer Twonks hate bug fixing.
• Twonks like patterns but can’t spot duplication.
• Twonks are obsessed with performance but don’t understand maintainability.
• Many Twonks become Scrum Masters. Usually because someone else has identified them as a Twonk and promoted them away from coding, or design, or whatever (the manager is almost certainly a Twonk, in case that wasn’t obvious).
• All Architects are Twonks. Only a Twonk would want the job.
• All heads of departments are Twonks for the same reason.
• So is everyone in HR and hence why so many Twonks have jobs.
• And so are most CEOs.

(The Angel always likes to hear of new Twonk Criteria)

Now here’s the really bad news. If most of the people you work with are Twonks then, probabilistically speaking, its likely you are too.

Don’t be too downhearted. The Angel knows that many Twonks have elevated themselves from the mire of mediocrity. The first step to a life free of twonkiness is self-awareness. The Self Aware Twonk begins to see herself in a true light. Her new found awareness means she can curb the worst of her counter-productive behaviour and from there, who knows. She can sometimes even turn it around completely.

And the Angels advice to SATs is that the best first step for a newly aware Twonk is... Agile. Go read about Extreme Programming*****. Adopt it and practise it vigorously, and without question. If you can do that the Angel thinks you may well be on the road to recovery.

The Agile Angel was once a Twonk.

*Incidentally, she’s pretty sure the term Twonk was originally a happy combination of the the word Twat and Plonker. How fortunate, if a little unkind.

** In her experience the Angel has found the Twonk distribution to be very much lower in contractors. Not consultants however who are, in the same way as Architects, Twonks by the very nature of what they do.

*** This is most likely due to the fact that most managers are themselves Twonks.

**** She suggests a ration of 1:3 as being the maximum acceptable NT3 ratio. Unfortunately a ration of 1:10 or higher appears to be the norm.

***** Picking a different flavour of Agile is a classic Twonkism.

The Oldest Excuse in the Book

The Agile Angel often reads stuff from people about how Agile isn’t working for them, or how its not right for their situation. A common answer to this used to be:

‘You’re probably not doing it right.’

This was usually accompanied by thoughtful, intelligent advice about how to improve the situation. And this was a pretty good thing despite such advice often going unheeded.

Now it seems that things have changed. No longer is this answer acceptable and in fact it is considered by many to be a sign of weakness in the Agile argument. Its the ‘oldest agile excuse in the book’.

She is finding this increasingly irksome.

She wonders if its all about a modern obsession with the quick fix, the instant solution, the two-day-training that solves-it-all. She cannot understand why most software professionals won’t face the fact that to be skilled at anything takes time. Agile is no exception. Even if you are lucky enough to be a genetically-modified programmer with a conjoined, programming twin, learning the Agile skill set is still going to be an undertaking that’s measured in years not months.

For the reasonably gifted she estimates 2-5 years to reach a level of competence that might be bordering on ‘expert’. For the ordinary Twonk 5-10 is a more likely range, although in this case there are no guarantees. When you consider that the vast majority of developers are Twonks (and some even make a living teaching other Twonks) then becoming truly Agile is indeed a significant undertaking for any company and for most individuals. This is not a weakness of Agile. This is the nature of being a true professional or craftswoman.

Don’t be disheartened. You’ve got to learn something, right? At least with Agile you’re learning the right thing.

Practice, practice, practice. There are no quick fixes. There is no process or methodology that will make you successful if you don’t do the hard yards.

She suggests that those who doubt whether Agile works take a long look in the mirror. Just how long have you been developing and how long using Agile techniques? How much baggage are you carrying? How much effort are you actually prepared to put in to become a true professional? Most importantly are you absolutely sure you’re not a Twonk? Remember that a classic sign of Twonkiness is the inability to consider you might be one.

Peace.

Opening Statement

Agile* is the right way. Period.

The sheer wisdom and magnitude of vision that Kent Beck brought to our industry was, and still is breathtaking. The Agile Angel is a big fan. And she suggests you should be too.

But, alas, our industry is such a pillar of mediocrity.

We are offered a pure vision of the way software should be built, a way out of the darkness. And yet, instead of gratitude and respect we simply move to corrupt it. Even those who were amongst the most evangelical in earlier times now sound almost apologetic that they once held such strong beliefs. The Agile Angel is sad to see this has happened.

And why? What has brought us to this? How have we arrived at a place where....

When we say ‘if its not working for you then you’re not doing it right’, we are laughed at.

When we make money from dispensing wisdom we are branded charlatans, snake-oil saleswomen and worse by the very people whose coffers we are helping to fill.

When we suggest that Agile scales, is robust and is suitable for all we are told we do not work in the real world.

We are told, in condescending tones, that Agile is an improvement but that it is no silver bullet. We are told this and we accept it. We seem embarrassed. We capitulate to people who have never even read a book!

The Agile Angel has become frustrated and her contempt for the industry and her fellow professionals (ha!) grows daily. Enough.

Its time for some good old-fashioned straight talking. No pussyfooting around, no apologies, no water-it-down-so-we-fit-in mentality. Just the Truth.

*The Agile Angel uses Agile as a shorthand for Extreme Programming. She has always been suspicious of Scrum (and its bastard son Scrum-Ban) but over the years this has grown to outright contempt.