Thursday, 29 December 2011

TEDCEMBER: Trial, error and the God complex

TEDCEMBER hasn't been going well for the past few days. I've been watching the occasional video, but not finding anything interesting to blog about. I'm happy to say that Tim Harford's talk - Trial, error and the God complex, is an exception.

In Tim's session he describes what he (or a Doctor called Archie Cochrane) termed the God Complex - The absolute infallible belief that you are right, irrespective of the complexity of the problem. I blogged about something related here. Tim argues that our economy and interactions are too complex to understand, predict and control. Instead he suggests we already have a system for solving complex problems - evolution. Variation and selection. Trial and error.

Trial and error should be encouraged within our social, business and political systems. Criteria for success (and the mechanism of measurement) should be decided in advance. Feedback should be sort and acted upon as quickly as possible - the most important discriminator for a successful evolutionary system is the time taken for it to adapt. Most importantly we as individuals must learn to tolerate failure. Not the monumental failure of our government funded IT projects, but the small, correctable failures that enable us to evolve systems that reliably solve problems of a complex nature time and time again.

Wednesday, 21 December 2011

TEDCEMBER: Why to Believe In Others

Once again I've had to search through several candidates to find a TED talk worth another blog post, and once again I'm not entirely sure I've succeeded. Viktor Frankl's short talk on why to believe in others was funny, but lacked supporting evidence. His argument, that we should be to overestimate our fellow man's potential, because to do otherwise will result in them falling short of it, does hold some sort of truth. It's a common enough tactic to award someone recognition or rank prematurely to motivate them to "step up, but while I've seen this work, I can also imagine it failing. Unfortunately Viktor fails to elaborate on context or guidelines for applying this type of strategy.

Monday, 19 December 2011

TEDCEMBER: A Police Chief With A Difference

I'm not at all satisfied with todays TED talks. I tried at least three before I found one that sparked sufficient interest to be worth a blog post, and even then only just. In "A Police Chief With A Difference", Kiran Bedi talks about how she got a job as Inspector General of Prisons after giving the Indian Prime Minister a parking ticket. The only bit I found worth repeating is her assertion that crime isn't addressed by preaching, it's address by reflection. I wonder whether and this approach can be used to transform people in target driven or otherwise dysfunctional organisations.

TEDCEMBER: Using Our Practical Wisdom

Barry Schwartz's TED talk on practical wisdom didn't throw up anything new, but it's nice to know that other people share my views on target driven behaviour. He also argued the case more clearly than I typically do, so that's at least something I can learn from. Barry starts his talk by expressing that there is a high degree of collective dissatisfaction with how our institutions are run. He's not wrong. If it's not the bankers, it's the politicians, or the police or the press. And don't get me started on the education system or health service.

Depressingly the typical response to these kinds of revelations are more of the very things that cause them in the first place. More rules, more incentives, more targets. The problem with RI&T is that they demotivate, demoralise and distract the skilled professionals who would otherwise be doing a good job, while preventing the incompetent and inadequate from early identification and intervention.

Barry argues that the solution to these problems is the opposite. We need systems that encourage people to demonstrate practical wisdom (the skill and desire to do the right thing) and since this is not how the majority of our institutions are currently organised, we need systems changers and systems thinkers in order to create them. I wholeheartedly agree.

Saturday, 17 December 2011

TEDCEMBER: How To Start A Movement

Today's TED talk by Derek Sivers was fantastic. In 3 minutes and 10 seconds it showed an insight into leadership and the human psyche I had never appreciated. A leader is just a lone nut with the courage to stand out, until he has one follower. The first to follow transforms the lone nut into a leader. The first follower is also an underestimated form of leader. It takes guts to publicly follow a lone nut. When subsequent followers join the movement, they emulate the first follower, not the leader. They don't risk being ridiculed but if they hurry they can still be part of the in crowd, and now the snowball effect really starts to kick in. Eventually the movement gets so big that those late adopters who were afraid of being ridiculed for following the original lone nut now start to feel vulnerable and exposed by not following. That is how you start a movement.

Friday, 16 December 2011

TEDCEMBER: How Great Leaders Inspire Action

Dan Pink contends that the three key ingredients that motivate people to perform cognitive tasks are autonomy, mastery and purpose. I want to learn more about the purpose motivator, so today have been searching for a TED talk to do just that. My first attempt was a waste of time, the second more interesting but not really what I was looking for, the third, Simon Sinek's "How Great Leaders Inspire Action", was right on the money.

Simon proposes that there is a pattern of communication followed by successful leaders, it's the reason why Apple products are so highly desired and why people were inspired by Martin Luther King. Here's the secret. When marketing our products, ideas or selves most of us start with a description of "what", followed by an explanation of "how" and finishing on "why", e.g.
We make great computers. Our products beautifully designed, simple to use and user friendly. We believe in challenging the status quo and thinking differently.
Want to buy one?
Great leaders inspire us by giving the pitch in reverse.
We believe in challenging the status quo and thinking differently.The way we challenge the status quo is by making our products beautifully designed, simple to use and user friendly. We just happen to make great computers.
Want to buy one?
The theory goes that when we pitch a "Why" argument it bypasses the rationalisation part of our brain and gets straight to the part responsible for decision making,  trust and loyalty. When our own views align with of the Why pitch we become pre-disposed to the product. I'm no biologist but this at least passes the sniff tests.

The same argument goes for rallies. People don't go to learn what the speakers have to say, they go for affirmation of what they already believe. Just as those 200,000+ civil rights supporters did from the steps of the Lincoln Memorial in 1963, we follow leaders when they believe in what we believe.

Wednesday, 14 December 2011


Everyone deserves a break once in a while. Today I picked a TED talk I thought would be funny, intending to blog about something else. It's too good to go unmentioned. Next time you have 5.07 minutes to spare and are in need of a pick me up, it's well worth a watch.

Tuesday, 13 December 2011

TEDCEMBER: Optical Illusions Show How We See

Today I watched Beau Lotto's TED talk on how we see. I learnt that we see things differently depending on the context of what we're looking at and depending on what we've previously looked at. There are all sorts of parallels I could draw regarding how context and prior experience affect perception, but I suspect they'd be pretty thin straw men. You can probably tell I didn't find this talk overly inspiring.

Monday, 12 December 2011

TEDCEMBER: What happens when an NGO admits failure

Failure is a common theme within Agile projects - we understand the value in failing fast and early. The most effective teams operate in an environment where failure is accepted. To do otherwise leads to undesirable behaviour, failures are hidden, learning opportunities are lost, people avoid responsibility, less work gets done. In today's TED talk David Damberger discusses the failure of aid organisations and in particular the Canadian Engineers without Borders programme, so I was keen to see how his organisation treats the subject.

I'm happy to say the answer is with maturity. EWB Canada now publish an annual report and have set up a website where other organisations can openly discuss failure. It wasn't always so. David explains that the driving force came from the engineers themselves, they had to push their management hard to make it happen.

Think about this for a second. 100% of the rain collection systems David put in place in India had failed after 1.5 years due to inadequate maintenance and availability of spare parts. Another gravity fed water system suffered over 50% failure for the same reason. When he spoke to other engineers they had similar stories. The Canadian EWB management team initially preferred to hide this information rather than publish it, even though this would lead to other engineering teams making the same mistakes, wasting both the engineer's generously donated time and supporter's generously donated funds. Worse that this it would have resulted in inadequate solutions for those they were claiming to help.

The issue of hiding or punishing failure is systemic in organisations today. It needs to stop. Congratulations to David for taking a stand.

TEDCEMBER: The Danger of a Single Story

Today I watched Chimamanda Adichie, talk about the danger of a single story. It was well presented, effectively delivered but didn't resonate with me, and didn't need to be 20 minutes long. Her point, that when we have only one story of a person or people, that we create a stereotype that while not incorrect is incomplete; that when a person or organisation is powerful or predominant we have a  much wider set of stories told from different perspectives creating a more accurate representation, all seems so obvious it doesn't need to be said. I checked the comments and I'm in the minority. Maybe I'm missing something.

Saturday, 10 December 2011

TEDCEMBER: 3 Ways The Brain Creates Meaning

Today I watched Tom Wujec talking about how our brains turn information into meaning. I wish he'd spoken for longer, as the subject has more direct relevance to building successful products than any of the TED talks I've watched so far. The reason? It gave me the why. Why we should have walls dedicated to our product roadmap. Why we shouldn't limit ourselves to story cards but include photos, drawings, diagrams, maps and faces. Especially faces.

Why are faces so important? Well it turns out that our brain has approximately 30 areas that process visual information in parallel to form a multi-dimensional mental model. Tom's talk touches three of these. The Ventral Stream - our "what" detector (the part of our brain that puts a name to shapes). The Dorsal Stream, which locates objects in a physically embodied space and the Limbic System which causes emotional reactions. It's the part of your brain that causes you to go "aww" when you see a puppy.

The more dimensions we use when we describe a product, the richer our mental model will be, the quicker and more accurately we'll understand it, the more engaged we'll be while exploring it, the more ideas we'll generate and ultimately the more creative and imaginative the product will be. Faces are important, because like puppies they trigger emotional responses. So product walls should have imagery of people expressing delight, love and even loss, snowboarding in Canada or drinking cocktails in Barbados. A far cry from the the dull, perfectly aligned, text only 6x4 white index cards we see in most SCRUM backlogs.

The good news is there are a further 23 of Tom's videos here. I guess I know what I'm doing in January.

TEDCEMBER: Don't regret regret

I've been eyeing today's TED talk for a while and wasn't disappointed. In Kathryn Schulz's session on not regretting regret, we learn that regret requires both imagination and choice. The more opportunity we can see for a better outcome the greater our regret will be. This is why we regret missing a flight by 3 minutes more than if we miss it by 20, - it's more likely we could have done something to affect the outcome.

The things we most regret are our choices with regards to education, career, romance and parenting. This is probably because these things are difficult to remedy. Our response to regret is surprisingly primitive.

  1. Denial (I wish it hadn't happened)
  2. Bewilderment (I can't believe I was that stupid)
  3. Punishment (I could kick myself)
They are also perseverative - i.e. we keep repeating them over and over. My guess that this is an evolutionary trait from when making any mistake twice was far more risky than it is today.

To appease these unpleasant feelings of regret Kathryn suggests the following coping mechanisms:

  1. Find other people with the same regret - the example she gives is Goggling for regret+tattoo, you'll find 17 million other people with far worse tattoos than yours.
  2. To laugh at yourself
  3. Give it time
She leaves the fourth mechanism to her conclusion - rationalisation (a.k.a. spin). Focus on the positives, and if there aren't any, to remind ourselves that we should feel pain when things go wrong, to ensure we make better choices in future. 

I don't disagree with any of this, but on the occasions when I feel regret and the rationalisation engine kicks in, it usually allows me to move on, but I'm left with a nagging feeling that I've conned myself. There is however a more effective remedy. Empathy. We can empathise with ourselves just as we an empathise with others. So the next time you feel profound regret for your actions, ask yourself what need you were trying to meet when you took your decisions. It's not necessarily an easy thing to explain so I'll finish with an example.

About nine months ago I ran an evening session on behavioural driven development at SkillsMatter. It was the fourth time I'd delivered the presentation, but I hadn't dusted it off for a while so had taken the day of the event off to prepare. About a week prior I was invited to take part in a strategy day for one of my clients. I really like and respect the people at this company and felt honoured to be included. Unfortunately the date clashed with day of the presentation, meaning I would have less time to prepare. I accepted the invitation, and as a result the session was below par. Worst of all the video is available for all to see.

I regret that I didn't prepare properly, that I was lacklustre and that the audience didn't get as much from the presentation as they otherwise would have done. I've certainly learnt a good lesson, but knowing this doesn't make me feel any better. What does help is thinking about the need that I was satisfying by attending the strategy day - my need to spend time with people that I care about, respect and admire. When I remind myself of this, the discomfort associated with the regret vanishes instantly, which is why I believe self empathy is the most effective coping mechanism for dealing with regret.

Friday, 9 December 2011

TEDCEMBER: Make Something Good Out Of Something Bad

It's already 01:00 and I have a 06:42 train to catch tomorrow. Unsurprisingly my only criteria for today's TED talk was that it had to be short, and short it was, but even then (excusably) light on content as the presenter, David Hoffman had lost his house and a large portion of his life's work in a fire. Rather than mope he's been sifting through the charred remains and making a film about them because he was taught as a kid,
"You gotta make something good out of something bad."
 I have a feeling this blog post is so bad there's no good to be had. Apart from that I get to go to bed now. gn.

Thursday, 8 December 2011

TEDCEMBER: How many lives can you live?

Today's TED talk by Sarah Kay turned out to be a break from my preferred theme of psychology. In it Sarah describes her childhood desire to live multiple lives (a princess, a ballerina and an astronaut), her disappointment when she realised we only get to live one life and her solution of immersing herself in other peoples stories. The talk (and poetry) were utterly absorbing, and reminded me of three things:

1. Scott Adams (Dilbert cartoonist) suggests the secret of his success not that he's in the top 1% of cartoonists, or top 1% of public speakers, but that because he's in the top 1% of public speakers who are also cartoonists. He's essentially living two lives. I believe USPs are the same thing. To attempt to differentiate ourselves or our organisations on a single USP is unrealistic for 99% of us at least. Easier to find a combination of things that make us unique and attractive even if it narrows our target market.

2. When designing a new product, IDEO form a product team of people with different skills and backgrounds with a flat structure and encouragement for wild ideas (there's a video of their process here). I would like to see backlogs and software prototypes designed this way. The more points of view initially on offer the better. The reality is often the opposite, with a small number of stakeholders, negotiating requirements via a business proxy, and little direct input from end users, development, ops etc.

3. I really should catch up with the guys at Ditto. They run a similar event to TED called campfire. The stories are always great, but what I most enjoy is meeting other attendees. Coming from an IT background it's incredibly refreshing to be amongst actors and musicians, people with significantly different lives and stories.

Tuesday, 6 December 2011

TEDCEMBER: Carl Honore Praises Slowness

Back in the day, I remember queueing in the rain for cinema tickets. The theatre usually had two films to choose from and if the queue was large, no guarantee that you would get to see either of them. Once tickets had been secured, there was a queue for confectionery, a queue for admission, a 'B' movie, an intermission (with adverts and ice-cream), then finally the main feature. If you couldn't get to the cinema before the feature was pulled, there was no Internet, Satellite, Cable, Blu-Ray, DVD or even VHS to fall back to. Your only hope was that in about five years time one of the four terrestrial channels might put it on as a Christmas movie so you could watch it on the mono, low def, goldfish bowel that passed for TV. As retrospectively painstaking as the cinema going experience was the combination of risk and anticipation meant it was far more exciting than the conveyor belt one we have today. This was the subject of today's TED talk, which kicks off with the soundbite,
"These days instant gratification takes too long"
Carl's point is we're constantly rushing, and that rushing may not be good for us. It may not even bring about the results we want. As example he recalls feeling impatient when reading to his son, the discovery of a book of one minute bedtime stories, and how it takes more than one minute for a child to feel secure enough to tell you about the problems they have had that day at school.

It's an important lesson for businesses too. The systems we work within require slack, not 100% utilisation. Without slack we not only suffer burn out, but there's little scope for continuous improvement. When our brains are actively focused on the job in hand the best we can do is make the existing system more efficient, but for the creative thinking necessary for radical improvement we need downtime.

TEDCEMBER: Daniel Goleman on Compassion

I'm interested in compassion because it's a powerful intrinsic motivator so I picked Daniel Goleman's TED talk on Compassion for todays blog post. In summary, studies show that when we stop focusing on ourselves and pay attention to other people, we're more likely to feel compassions. I was hoping for something more insightful.

Saturday, 3 December 2011

TEDCEMBER: Obstacles Are Springboards

Staying with the "limits" theme I watched Amy Purdy's "Living beyond limits" talk today. It was in a similar vein to Caroline Casey's session and just as inspiring. The key message I learnt from Amy is that we should treat our obstacles as opportunities for imagination and creativity. They are springboards to push off, not walls to push against. 

TEDCEMBER: Looking Past Limits

Today's (yesterday's) TED talk was by Caroline Casey and entitled Looking Past Limits. Caroline has a surprise that I won't spoil for you. It's a brave talk that's extremely personal, honest, inspiring and engaging. A reminder to make any presentation personal.

Thursday, 1 December 2011

TED Talk every day in December

Quite often someone sends me a link to a blog, podcast or video that they've found interesting. It's usually while I'm at work, or otherwise engaged. I archive the email and promptly forget all about it, which is a shame. I'm missing out, so I've decided to address the situation. It seems November was the month for doing "something" every day. Writing poems, novels, growing moustaches or video blogging. I've always been a bit late to the party so instead I'm going to watch a TED talk every day in December, then blog about it. Starting with this one...

According to Matt the benefits are surprising. 30 days is the right amount of time to form a habit (or lose one), and by repeating the process each month with a different challenge, your self confidence grows and you become more adventurous. Small changes are apparently more sustainable than big ones. The video was short and sweet - only 3m 37s.

Already looking forward to tomorrow.

Sunday, 27 November 2011

Performance and Concurrency Testing - The Poor Cousins

Rob Fletcher has written an interesting post on the challenges associated with functional testing. I agree with everything he says, but recently my appetite for testing has lead me elsewhere and it's probably about time I wrote something about it. Here goes...

Unit, integration and functional testing have a good deal of momentum within the development community. There is a wealth of decent open source software and a tonne of support material readily available, but there are two areas of testing which aren't well supported and it's bothered me for some time. I'm talking about performance and concurrency testing. Performance testing encompasses load testing, soak testing, benchmarking etc(all of which are likely to require some degree of concurrency). By concurrency testing I'm talking about specifically trying to verify thread safety, or checking for deadlocks, etc.

Project teams frequently defer this type of testing to near the end of development and treat it as a short, one off activity. Doing so is a mistake, since if (as Rob points out) test data is cumbersome to set up for a functional test, it can be an order of magnitude more difficult for a load test. Instead of hard coding the test data you usually need to generate it, typically in accordance with some complex validation rules. Just generating the required quantity of test data can take hours or days. Even worse than this is the cycle time or "cadence" problem that Rob writes about. If a soak test takes 24 hours to run, but falls over with out of memory errors after 12, then takes 3 attempts to fix, you'll have wasted the best part of a week without actually completing a single test run. If you do manage to complete a successful test run, can you trust the results? Was the throughput limited by the test client, by the infrastructure or by the system under test? How would the results have changed if you'd tuned the infrastructure differently? Were your test data and test operations an accurate representation of live? More often than not performance and concurrency testing raise more questions than they answer.

The reasoning behind running these types of tests once and only once is because they are painful and expensive, but if we've learned anything from continuous integration it's that when something causes you pain, do it more frequently, not less. We've also learned from unit and functional testing that it's better to get feedback early. Both good reasons to automate your expensive performance / concurrency tests and run them as often as feasible. I like the idea of a nightly build which runs the load tests and trends the results. If the system suddenly starts performing badly, it should be easy to narrow the problem to a small number of commits. The downside of such a system would be the maintenance, although I suspect it wouldn't be as high as for functional tests.

Strangely the development community has not embraced performance and concurrency testing in the same way that it has done with unit, integration and functional testing. Commercial products such as LoadRunner exist, and there are open source alternatives such as JMeter. My primary objection (I have many more) to these tools is that they are not designed for developers, yet due to the technical difficulties in generating representative test data it is typically developers who end up writing these kind of tests. Grinder looks closer to what I'm after, but it seems so complicated. I want a tool that allows me to write tests in Java, has access to my project classpath, lets me leverage any other java library that I choose, runs from my preferred IDE, integrates with my build and that can record results over time. i.e. jUnit + [performance / concurrency toolkit] + database.

So I've started to write one - Julez. It's early days, but has been lots of fun so far. I should also thank Frank Carver for applying his Jedi mind tricks to keep the project small and lightweight.

Monday, 17 October 2011

Misadventures with Legacy Code

I'm pleased to be presenting my session "Misadventures with Legacy Code" at EnergizedWork's November TekTalk on Wednesday, November 9, 2011. Further details available here.

Friday, 29 July 2011

Build Barrage Balloon

When the build breaks people need to know. Our build server is hosted on a remote linux VM, so we play build noises using a patched version of the Jenkins notification plugin and my own notification client, Jinkies. But playing a build noise isn't enough - we need to know that the problem is being addressed and have a perpetual reminder not to check in.

In the past we've used comedy build hats, but on a hot day wearing a hat can get uncomfortable. On another project we used a rubber chicken on a pole, but it wasn't visible enough. One December we even tried a mini Christmas tree (with sign saying "please don't break my trunk"), but it took up too much room on the desks. Short on ideas and limited to the local shops we hit upon the idea of a helium balloon. They're cheap, highly visible, portable and take up no desk space whatsoever. There's also a wide variety to choose from (Get Well Soon, Bob the Builder, Jolly Roger, etc). The only downside is you have to keep replacing them every few weeks. Ah well, it will do for now.

Wednesday, 27 April 2011

Energized Work are Awesome

There's so much self promotion on corporate web sites, it's impossible to work out what's real and what's marketing. Blogs tend to provide a bit more genuine insight, but when someone else writes something nice about you, there's a good chance it's true. Here's what Lisa Crispin had to say about my friends at Energized Work.

Friday, 22 April 2011

A Case For Test Driven Development

I've had to sell TDD into my last two consultancy roles. Here's the case I presented. Thankfully I was successful.

TDD is not Unit Testing
The purpose of TDD is not to reduce defects, but to encourage good low level design and provide fast, targeted feedback when things do not work as expected. This is not to say that you cannot write well designed or clean code without TDD, or that using TDD will guarantee that you do, just that since poorly designed code is difficult to unit test, if you start by writing the test you are goaded into keeping methods small, responsibilities separate, classes loosely coupled etc. This is just one way in which TDD differs from unit testing (which may be done after the ‘real’ code is written). Another is that if you adhere to TDD practice you are required to examine the code after writing a passing test, in order to make small improvements to it, such as factoring out duplication. Once again there is nothing to prevent you from doing this without TDD, however if you follow TDD this behaviour is expected and you are protected when doing so by a regression test suite.

Functional Testing is Insufficient
Where TDD and unit testing do overlap is in providing the benefit of fast, targeted feedback. If in modifying the code base you introduce a bug, it is more cost effective to find it immediately, before the context of the change has been forgotten or complicated by further modification. If you rely solely on functional tests then you are limited in three regards. Firstly, a functional test is less likely to pinpoint the origin of the defect in the same way a unit test can, typically making its diagnoses more time consuming. Secondly, a functional test takes longer to execute than a unit test. A defect can break multiple tests and may not be fixed on the first attempt. As a result the broken tests are re-run repeatedly so the faster they run the better. Finally it is dangerous to rely purely on functional tests, because it is difficult to fully exercise the internal workings of a system when you only have control over its extremities. A unit test by definition provides direct access to the components within a system, and is therefore better able to fully exercise the behaviour of those individual components. As a result unit tests can detect defects that may otherwise be missed by functional tests. The cost associated with missing a defect early is typically high, because once out of development the defect needs to be recorded, managed and fixed. Often the whole release is invalidated and has to be rebuilt, reinstalled and retested. Clearly the best time to find a defect is just after it has been introduced.

Regression Tests Enable Sustainable Pace
The next benefit of TDD is that by placing an emphasis on refactoring, and by providing the safety net of a fine-grained automated regression test suite you are encouraged to keep producing well written software. This is even more important in an environment with frequently changing requirements, since it is the safety net that allows you to make wide reaching changes to your code base while minimising the risk of introducing defects. Were it not for this safety net, developers may be tempted to reduce risk by minimising the changes required, even if this means compromising the design, i.e. hacking. Maintaining poorly designed code makes further changes more risky still, and begets yet more hacks. Over time the quality of the code base can degrade to a point where delivery is unacceptably slow and release candidates repeated fail formal testing. In contrast, TDD helps achieve a sustainable pace for the lifetime of the application.

TDD Encourages Clear Requirements
TDD does more than encourage good design and providing fast feedback however. With TDD you start by writing an assertion. This provides focus. If you cannot assert what you want to test, you cannot continue and have to seek clarification.

TDD Motivates Developers
Another benefit is that TDD is in harmony with the typical developer mindset. People who enjoy writing software are problem solvers. Good developers enjoy writing software, but don’t necessarily enjoy writing tests. By writing the assertion first and seeing it fail you turn a chore into a challenge, meaning motivation is intrinsic as opposed to extrinsic, which studies have shown yields better results for cognitive tasks.

Tests Document Actual Behaviour Rather than Expected Behaviour
Lastly TDD provides “living” documentation of what the system actually does. Requirements, design documents and even comments / javadoc can get out of date, but the tests communicate how the system really behaves. This can make it easier for a developer to maintain code they have little or no experience of. In recognition of this testing libraries are evolving to the point where it is now possible to write tests automated as English specifications (see spock, JBehave, concordion).

The Cost Of TDD
I have been using TDD in Agile teams for about six years. My first observation is that providing you write the test first, it does not take very much longer to write the test plus the real code, than to just write the real code. The reason for this is that modern IDEs offer automatic code completion – they will create the classes and methods for you from your test. My second observation is that test driven code involves less time debugging, so the overall time spent in development for a release is actually less than if the code had been written without the tests. More defects also tend to be found in development, rather than during formal testing, reducing the time for each release further. My third observation is that since TDD demands refactoring, and provides a mechanism for doing this safely, changes do not become exponentially more difficult (and therefore time consuming) over the lifetime of the application. Unfortunately there is little empirical evidence to support or refute my observations. The best I could find is this report, which compared the findings from 13 other studies. It concluded that:

“TDD seems to improve software quality, especially when employed in an industrial context. The findings were not so obvious in the semi-industrial or academic context, but none of those studies reported on decreased quality either. The productivity effects of TDD were not very obvious, and the results vary regardless of the context of the study. However, there were indications that TDD does not necessarily decrease the developer productivity or extend the project lead-times: In some cases, significant productivity improvements were achieved with TDD while only two out of thirteen studies reported on decreased productivity. However, in both of those studies the quality was improved.”

Critisms of TDD
The most common critism of TDD is that it takes a big investment. I disagree with this since I believe the cost of not doing TDD is significantly greater than the cost of doing it. Another is that TDD will involve a learning curve. I stuggle to comprehend this argument since using the same logic one would conclude that we shouldn't write simple code since this requires a learning curve too.

There are some other critisims that I do agree with however. TDD may be not be appropriate when prototyping or writing exploratory code, when what you are really trying to do is understand the problem space. After you do understand the problem space you either need to throw away the code and test drive from the start, or retro fit the tests. The former feels wasteful, the latter feels like a chore. I have also found TDD to be burdensome when fine tuning heuristic algorithms, e.g. the weightings used by a search engine to determine relevance. Test driving the code to call the search engine is easy, but creating a suitable set of test data and tweaking the weightings until the resutls are desirable is time consuming and usually takes several iterations.

My final critism of TDD is that it can require you to expose class variables that would otherwise remain private in order to assert state. Since the tests usually live in the same package as the classes under test this is often done by creating a package scoped accessor, and while undesirable is only a minor infringement.

So there you have it. My case for TDD. I'm sure there are benefits that I've missed. When the boat stops rocking I'm going to push for pair programming too.

Sunday, 13 March 2011

Designing for Marv

One of the best lessons I've learned in recent years is to design for Marv. Marv is a fictional character who objects to anything he's unfamiliar with. This makes continuous improvement extremely difficult since tweaking the process or switching to a new software library will be met with resistance. One benefit of working with Marv, is that you won't be able to introduce new ideas without at least convincing him they will bring a net benefit. The bad news is that even if an idea does have a net benefit, you'll constantly be reminded of its flaws, and this can get annoying to say the least. The solution is to polish out those flaws before exposing it to Marv in the first place. Solicit help from a couple of "friendlies", trial the idea in isolation, then make it's implementation painless. Now Marv will have nothing to complain about and you'll enjoy the benefits of your idea all the more.

Saturday, 12 March 2011

Compose, Conduct, Compromise or Cultivate?

So far I've seen four types of Agile coaches, those that compose, those that conduct, those that compromise and finally those that cultivate. Those that compose, are skilled coaches of great experience. They instinctively inspect and adapt, and constantly experiment with the process. Working on a team like this is electrifying. It generates it's own energy and momentum. Nothing seems impossible, and yet it's unsustainable. The team and its success are too reliant on the composer, who becomes a single point of failure. When they move on, the energy will dwindle. If you're lucky a partial clear out, and injection of some new blood can reinvigorate things. If you're not the project will become a shadow of it's former self, serving only as a reminder for how good things used to be.

The next type of coach conducts the project according to the dogma of a prescribed methodology even in the face of common sense. When I was less experienced there were several Scrum practices that I didn't like, but assumed this was because of my lack of understanding. It turns out however that at lot of them are unnecessary or wasteful. Take the practice of public commitment. Just what is the team committing to? If scope, then if you estimate badly, the only way to deliver within a fixed iteration is to drop quality. If quality what's the point of committing at the start of each iteration, since quality should always be high? Working on a prescribed project can be demotivating, but isn't anywhere near as bad as working on a compromised one (although If you choose to argue I will concede the point that prescription is a form of compromise).

A compromised project is one in which some fundamental value or principle is disregarded (usually because it doesn't fit with what the customer wants to hear). A great example of this is off shoring. Communication is one of the original XP values, and frequently makes the shortlist for things companies say they do badly. So why insist on making it virtually impossible by separating the development team and business people, not just by distance, but by language and culture as well? If the aim is to reduce costs, follow John Seddon's advice. He says when you attempt to manage costs, you invariably increase them, but when you manage value, costs automatically decrease. The way to manage value, is to ensure your product team can ship needed and high quality code without inhibition. This is only possible if the developers can effectively communicate with the product owner.

The final category of coach doesn't coach at all. Instead they cultivate, encouraging the team to compose for themselves and to understand and influence the greater business ecosystem they operate within. Only then will they be able to adapt and survive, without compromise, and thereby become self sustaining.

April London Groovy & Grails User Group Meetup

I'm please to be presenting my "Improving Collaboration with Selenium IDE" session at this April's London Groovy & Grails User Group Meetup.

    Monday, April 18, 2011 6:30 PM
    The Skills Matter eXchange
    116-120 Goswell Road London

Click here to register an interest and here to see what I'll be talking about.

Thursday, 10 February 2011

Go with the flow

One of the major problems that Agile tries to solve is the big bang approach to software development. With Waterfall, you do big up front analysis, followed by big up front design, followed by a long period of development. Testing usually gets squeezed because of time pressure, and integration is done by the seat of the pants. There are several flaws with this approach - you don't get any return on investment or learn how valuable the software is until it goes live. There are lots of projects that never go live, or that when they do turn out to be worthless. I'd much rather learn this lesson after three months, than one year.

Scrum (and other Agile methods) attempt to dampen this graph, by delivering little and often, in what is called a sprint. The initial release may take a few months, but once live, the software should be updated regularly. I've worked on projects with one month, two week and one week sprints. Returning to our principles of fast feedback and acknowledging we would like rapid return on investment, it's clear that the shorter the better. But is a short sprint really the best we can do? Why constrain ourselves to the artificial notion of a sprint at all? Why not pull as much work through the system as our capacity can sustain and optimise the flow so that there aren't any bottlenecks?

One argument is it's necessary to plan and co-ordinate releases. If you only release once a year, it's likely that your release involves several manual steps - it's not worth the investment to automate it. When you release every week you learn to automate everything - the repeating opportunity for fuck-ups means it's just too dangerous not to. When you have a high test coverage and a fully automated deployment why work to iterations at all?

Abandoning iterations means rethinking the planning game. Instead plan on demand (as and when a development pair need a new story). This way you'll know the maximum amount possible and leave your decisions to the last responsible moment. Long planning games are a bad idea anyway. At the start of the meeting everyone's fresh, and will argue a card to death. As brain drain creeps in people lose interest. I don't value estimation either. What's really important is to keep stories as simple as possible and to prioritise them well. While we're on the subject let's cut drop retrospectives too. Sure they provide a forum for continuous improvement but why wait until the end of the iteration to raise a problem and fix it. Waiting isn't an Agile principle that I'm familiar with.

Showcasing individual stories to stakeholders would be pretty hard to pull off, but more importantly doesn't make sense. Demonstrating stories separately would result in loss of context, but just because you keep a regular showcase doesn't mean you have to work to iterations.

Release whenever makes sense for the business. If that's every day, once a week or with a batch of related functionality do it. If you're constrained by external dependencies such as specific marketing dates that's fine too, but don't organise your development cycle to those release dates, go with the flow.

Thursday, 3 February 2011

Non Violent Communication

Back in February 2010 Simon Baker of Energized Work blogged about accountability in agile teams. He's right when he states "Saying nothing rather than speaking up is the worst thing we could do", but this doesn't make it easier to say "I think your code is crap". Even if you wrap it between two slices of Hovis, you're still handing someone a shit sandwich. I've tried all sorts of techniques for working around this, but rarely leave the conversation feeling good. I don't like hurting people and it doesn't matter how gentle or indirect I try to be, this always seems to be the result. Recently I came across a technique called "Non Violent Communication" which may just help.

The first aspect of NVC teaches how solicit different behaviour from people without upsetting them. The trick is to make a specific, positive request, expressing your own needs and feelings while being careful to avoid blame or judgement. This will encourage empathy and therefore compassion. When people feel compassion they usually respond with a genuine desire to help. The result is a win-win situation. It's like helping an old lady across the street - the old lady gets what she needs and you feel great about yourself for doing it.

So how does this work? Well a non NVC approach to criticism might go something like this:

   "Your code is too complicated"

Let's take a second to break this statement down:
  1. "complicated" is a judgement.
  2. "too complicated" implies there is something wrong with being complicated, and therefore something wrong with my ability to code.
  3. "Your code" implies blame.

   "It's your fault that you code badly"

Not only is the recipient likely to respond defensively, but you haven't actually asked them to do anything differently in future. The formula for making requests using NVC is as follows:
  1. Make an observation
  2. State how you feel
  3. Say what you need
  4. Make a genuine, specific, positive request.
For a request to be genuine, it cannot involve coercion (e.g. threat of punishment or offer of reward), or be replaced with a demand if the request is denied. A positive request is one which suggests action. A negative request is one which suggests the other party stops doing something.

So the equivalent NVC request might go something like this...

    "When you write methods that do several things or operate at different levels of abstraction I feel despondent because I have a need to work with a coherent code base. Would you be willing for me to show you how I would refactor this code so that I will find it easier to work with in future."

This time you haven't judged their code, you have simply made an observation about it. You have told them how you feel, but haven't blamed them for making you feel this way. You have expressed a need to work with a coherent code base and even if you disagree on what makes software coherent, they are likely to relate to this and feel empathy. As a result they will probably also feel compassion and want to help you. Rather than make them guess how to help, you make a specific, positive request. The request is genuine if it has no strings attached and if it does not turn into a demand should they refuse.

The NVC approach is far less confrontational and reading the above I think it would be quite difficult for someone to refuse, but supposing they did:

   "I don't have time to sit with you and help you understand my code. I think it's perfectly readable and if you can't understand it that's your problem"

Using NVC you can't demand the other person does what you want. Demands limit us to two responses - compliance or rebellion. Compliance against our will leaves us feeling abused and resentful. Furthermore when we do something as a result of coercion we rarely do it to the best of our ability. Rebellion risks escalating the situation and also leaves us feeling unhappy. When dealing with a refusal, the NVC approach is to empathise with the other person, then to make another request.

   "I understand that you feel under pressure, and are probably frustrated when I ask you to do something you think is unnecessary, however when you refuse to let me show you how I would refactor these methods, I feel concerned for the quality of our code base. If other members of the team agree that it is worthwhile would you be willing to work with me then?"

and so on.

The second part to NVC teaches that aggressive or violent language is typically an expression of a deeply felt, unmet need. Instead of responding to what was actually said, you should focus on exposing the unmet need and empathising with the other person. Once the need has been exposed and sufficient empathy has been given you will find the tension vanishes and a constructive conversation can be begin. Taking our example from the opposite angle, what if someone were to aggressively criticise you for writing overly complicated code?

Tim: "Your code is too complicated!"

Me: "Are you feeling frustrated because you are finding it difficult to follow or update code that I have written?"

Tim: "Yeah, it's totally minging. The methods operate at different levels of abstraction and do multiple things"

Me: "I can see how irritating it must be to work with code you find unpleasant, however when you say that my code is too complicated I feel defensive and I have a need to work in an environment where people are spoken to with respect. Would you be willing to sit down with me and show me what it is about my code that you dislike so that we can resolve this agreeably?"

Instead of responding to Tim's statement the NVC approach is to guess what he is feeling. Don't worry if you guess wrong, he's likely to give you more clues. If you guess right, empathise by reiterating what he has said. It may be that Tim has several unmet needs, or that he needs more empathy than a single response, but repeat the process until you feel the tension lift. Then start with your NVC request.

When I started practicing NVC I was concerned that my language would be formulaic and trigger an adverse reaction, however once you are experienced with the process it's possible to short circuit it a bit. Another criticism is that it takes a lot of patience and time. I find the opposite - it takes less time and effort deal with a situation pleasantly when it first arrises, than to foster resentment by bottling up emotions or demanding compliance.

One frequent question is what do you do if repeated attempts at NVC do not work? For this I refer back to the NVC bible. It would not be practical to attempt to stop a mugging by tapping the aggressor on the shoulder and telling him you feel concerned for the safety of the victim when he attempts to rob them. As such NVC does not discourage the necessary use of protective force. I think in business the same applies, but the timescales are different. If after genuinely trying NVC the quality of someone's work is still lacking then express your concern that they are not producing adequate results, and ask if there is something else that they would rather be doing. Your other option is to fire them, it may be best for all concerned (see section 2)

Tuesday, 11 January 2011

Intrinsic Motivation

When we want people to do something for us, we often use extrinsic motivators. We offer rewards or punishment, carrot or stick. Sometimes we use coercion. The trouble with extrinsic motivation is that it leads to poorer results. If you're doing something out of duty, guilt, to avoid penalty or to seek reward then you're not doing it because you actually want to.

The alternative is intrinsic motivation and it's incredibly powerful. I recently joined a debate on whether the recent rise in VAT was justified. Not normally something I would have been interested in, but because the posts had started discussing libertarian philosophy I got involved. Pretty soon I was arguing against the existence of a social contract, reading up on 17th century philosopher Thomas Hobbes and researching German politics around the time of World War 1 (The Act of Enablement which validated to Hitler's dictatorship would be legitimised by the existence of a social contract). What? History? Normally I can't stand the stuff. Yet because the motivation was intrinsic (it came from within), I couldn't get enough.

So one of the ingredients for intrinsic motivation is purpose (In the above example p'owning the guy who thinks because I was born I consent to be governed). Another is autonomy - the minute you start telling people how to do things to a degree beneath their perceived level of expertise, motivation will suffer. The final ingredient is mastery. People do things because they like getting better at them. I stopped enjoying playing the piano when I stopped improving. My friend Ron Ballard stopped playing the saxophone for the same reason.

The best way I've found to achieve this in business is to hire people who enjoy what they do (they'll be doing it outside work too), then let them run. You still need to pay them however!

For further reading see here and here.

Saturday, 1 January 2011

A Beautiful Mind

Knowingly having a closed mind would be pretty stupid, so I'm willing to bet most people like to think their minds are open. But what about you? Is your mind really as open as you'd like to believe?

A friend introduced me to Libertarianism at the start of last year. Libertarianism is a political philosophy derived from a simple and comparatively consistent set of ethics, which are in turn derived from natural law. Natural laws must be true at all times and in all places, so for example it is a natural law that human beings are fallible. It is another natural law that human beings strive to fulfill their needs, which I will simplify to "the pursuit of happiness". Therefore a Libertarian ethic is that man has the right to pursue happiness, although he cannot legitimately do so if his actions violate the rights of another. He does not however actually have a right to happiness. Fundamental principles in Libertarian philosophy include that of private property and non-aggression, both of which are violated by the state, and therefore Libertarians believe in the abolition (or drastic minimisation) of the state.

Wow! Abolition of the state - that would never work... or would it? Now the point of this post isn't to advocate Libertarianism, but it is interesting to describe what happens when you attempt to explain Libertarian Philosophy to the uninitiated (as I have failed to do on numerous occasions). To start with things go well. People like the concept of natural laws and generally accept the private property and non-aggression principles. This is unsurprising since natural laws are a seemingly harmless enough concept not to threaten our world view, and the private property / non-aggression principles are already incumbent within capitalist societies. However the minute you argue that these principles are inconsistent with the behaviour of the state, your subject will aggressively spring to the state's defense. It no longer matters that they may have bemoaned the government for incompetence and inefficiency, the once potential convert will predict chaos, drawing unfounded conclusions, highlighting edge cases while ignoring the gross imperfections inherent in the current statist system. I have yet to find anyone who can form a rational counter argument and yet no one has conceded that Libertarianism has merit - it is simply too different from what most people are comfortable with.

This reaction is described in Plato's Cave and reminds me of when I first encountered eXtreme Programming. I had long been schooled in Waterfall, and despite projects frequently being delivered late and falling far short of their promises, I believed that if only the business analysts would do their job, and the developers would implement the design (when I was an architect) or the architects would design something sensible (when I was a developer), then the software would be of high quality, do what was required and be delivered on time. The consultancy I worked for was small and so survived because they outshone the blue chips. This meant we delivered our parts of the projects on time and within throwing distance of what was required, but typically at the cost of quality - and yet I still believed if people did their jobs (and the customer stopped changing their mind), we would get the magic trifector. It never crossed my mind that Waterfall may be at odds with our natural selves. That human beings are terrible at prediction, estimation and producing riveting, unambiguous technical documentation.

I had heard about XP, but never took the time to understand it properly. When I was first thrown into an Agile project I rejected the methodology on the basis that without a signed off requirements specification there would be no agreement on what was originally requested. I refused to believe that TDD could be used to drive out design, or that architecture could emerge. It didn't matter that my world view had failed to deliver anything more than a polished turd (you have to freeze it first), Agile was for cowboys, crackpots and theorists with no place in the real world. Chaos would ensue.

Thankfully the coach, Paul Beckford had both thick skin and incredible patience. Eventually I began to see what I have previously overlooked. That XP was a highly disciplined development methodology, which cut out the middle man and replaced contracts with early feedback and trust. I remember when I first started realising I had been wrong. I felt small, almost humiliated - certainly vulnerable. The foundation (or pedestal) upon which I had erected my ego was beginning to crack. At the time the sensation was unpleasant, but now I look forward to this feeling because as with Agile and XP it means I am progressing, that I am changing the way I think, that I am hopefully replacing my old broken paradigm for one that is better (although probably still broken). It's not something to be afraid of, it's something to actively seek out and celebrate.

Do you recognise and welcome this feeling? Have you felt it recently? Is your mind really as open as you'd like to believe?