Testing Times for Testing

Went to the Extreme Tuesday Club (XTC) last night. Talked to a couple of guys from the Big Media Company and then to a couple of guys from uSwitch.com. There was also a bloke from an investment bank (Josh, not his real name).

The bottleneck was the QA guy

Curiously, all the conversations - I don't know whether there had been a talk about it or something before I arrived - were about testing. The Big Media Company guys were doing Kanban and Kanban had shown them that the bottleneck was "the QA guy". And they were wondering how to get round this. The guys from uSwitch.com had taken what sounds like a really radical decision and just got rid of their dedicated testers. But they said that the result was that the developers took responsibility for the code. Of course, you can only really do this if you've got TDD (they were calling it BDD) in place. You write your automated acceptance tests with the business people and then you code until the tests past - a common theme from both the uSwitch.com and Big Media Company guys was that you release stuff when it's ready, you don't wait for the end of and iteration.

Testers focus on finding bugs without regard to value

Why did uSwitch.com get rid of their testers? Well, the testers weren't really on board with Agile, and one thing you have to careful of is anti-Agile diehards who bring progress to a halt, but the testers were also focussing on bugs without regard to value. The developers at uSwitch.com keep an eye on the error logs from the live site and they keep an eye on the conversion rate - how many people who visit the site actually make a purchase. If something causes the error logs to spike, or the conversion rate to drop, they're on it. The focus is on delivering value to the site. Another knock-on effect of not having any testers is that the business people, the product owners, have to "be their own domain experts". Again, another theme that emerged from last nights discussions is that there is a temptation to leave final responsibility for the product with the testers. Testers can be expected to have a detailed knowledge of how the system should work, but they're unlikely to have a detailed understanding of which bits of the system are of value to the business.

Offshore testers, are "paid by the bug"

Josh worked for a merchant bank that was still clinging to traditional waterfall models of development. He'd had some success on a few projects in introducing some Agile practices, but again, testing was a problem. In order to make sure that everything worked as it was specified, testing was done offshore and the offshore testing company were pretty much paid to find bugs. It would be very hard to expect this company to know, or to care about the business objectives of the company. So the list of bugs that was sent back by this offshore company had no prioritisation in terms of business value.

Josh also raised the problem of time with the traders being very valuable, that all the time that a trader was talking to them, he was losing money. We talked about whether the amount of time the trader spent on the software was going to be the same in an Agile project and in a conventional waterfall project. The guy from uSwitch.com told a story about some work he'd done at a previous company, where he'd traded in his desktop machine for a laptop and just gone and sat with the guys who needed the software. He'd watch what they were doing and occasionally ask them questions, he'd also get to show them the software he was writing as he was writing it.

Quick - we need a crisis!

We talked about there being no way of persuading people to go for this without actually giving them the experience of doing it. You could try to explain the benefits of an Agile/Lean approach until you were blue in the face, and it probably still would do any difference. One thing that we thought might make even a merchant bank take such an approach was if it was seen and understood that their competitors were doing something similar. We agreed that very few people take such radical approaches when they're already making money. Even the Japanese (and then only some Japanese) only tried these methods when their country had been defeated in a war and economically ruined. We discussed some ways of artificially creating these crises. The second time I'd had this discussion in a week.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Technical Aspects of Agile – Two-day course

Aimed at developers and team leaders who are already familiar with Agile approaches, this course with three important technical aspects of Agile software development.

Pair Programming

To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposite - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are found in the code.

This course covers the very good reasons for introducing pair programming and how to deal with some of the potential objections. It also deals with how to start pair programming - what are the do's and don'ts and provides course participants with some hands-on experience of programming with other people.

Test Driven Development

The practice of writing a failing automatic test for each piece of software functionality, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course gives participants experience of writing tests and then coding against them using the well-known testing framework JUnit.

Re-factoring

As software development progresses on a project, code gets messy and changes in one place cause unexpected problems in others. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the code base.

Attending this course will allow you to: transform the way you write software by getting hands-on experience of three important technical aspects of Agile – Pair Programming, Test Driven Development and Refactoring.

Suitable for: Software developers and leaders of software development teams. Working knowledge of the java programming language required.

Contact: Mark Stringer
Email: mark@agilelab.co.uk
Mobile: 07736 807 604

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Notes from a fry-up lunch

I had a fry up lunch on Wednesday with a friend of mine who's a developer and two of his fellow developers (he can own up in the comments if he wants to) a few things came up in conversation that I want to note down here - I might write longer pieces on them later.

• Quote: "The two projects that we made money on are the two projects where we said [admitted?] that we don't know". The standard case where the customer comes to you and says "How much for X" and you say Y pounds RARELY MAKES MONEY! But the model where the customer come to you and says "How much for X" and you say "Mmm, dunno. Do you want to pay me a little bit of money to have a look?" THAT MAKES MONEY! Maybe you can't get there straight away, maybe you have to do some fixed price stuff to get to that stage, but isn't good to know where you should be heading?


• A compelling reason for becoming involved in open source is that you get the respect of your peers. You also get coached by people who know what they're talking about. This is very different from the kind of feedback that you get from customers which is all about bugs or things not looking the way that they should. Perhaps pair programming could be a kind of mini, in-house open source in this way.


• Related to this - the loneliness of the self-taught programmer. Most programmers are autodidacts - they teach themselves. This means that some areas are very strong and some areas are very weak. When other people look at their code self-taught programmers can feel very foolish. If you're a self-taught programmer and you're trying to work within a framework which is supposedly helpful to development, such as test driven development, or pattern-based design, this can be very traumatic and cause you to really lose self-confidence. Maybe this is why some guru/surgeon programmers are so reluctant to pair program.

The Loneliness of the Self-Taught Programmer

I have a friend who is very well-read in all kinds of fields. He has a PhD in Organic Chemistry from Cambridge University but he is also widely read in Russian and French literature. He bundled through the Penguin Classics well before we left sixth form. He likes all kinds of pop music and he also likes opera. What's more he achieved all this culture and erudition from a relatively humble background - most of his reading was done in the ice-cold back bedroom of a council house in West Yorkshire where he grew up.

Now aren't we all lead to believe that education and culture are a good thing? Shouldn't having read all these books have made my friend more confident and well-received when he did finally get into polite society? Well, it should have done, but there was slight problem. Pronunciation. He'd read Proust, he loved him, but he didn't know that his name was pronounce to rhyme with "roost" and not "roust". He loved Puccini but he didn't know that the word "aria" isn't supposed to rhyme with "Mariah".

And so when he did get into polite society, people laughed at him. People who had never read Proust still felt it was all right to laugh at his pronunciation. He learned the correct pronunciations really quickly of course, but he never forgot the sharp humiliation of those condescending smiles.

I was at lunch yesterday with 3 coders, one of whom I'd never met before. We talked about Agile stuff for about 10 minutes and he didn't say anything. Finally he said that working on a project that used Agile methods - particularly in his case, test driven development - had made him completely miserable. After he'd left the project he'd lost all faith in his abilities to code. It took him several months to regain any confidence.

Learning to program is a back-bedroom, late-night activity for most people. Most people who do it, are autodidacts - they teach themselves. There are university courses that claim to teach it, but most of them miss the mark. Either the course is too prosaic and equates teaching programming to teaching the syntax of a certain language or the course is too theoretical and imagines programming to somehow happen as a natural bi-product of understanding certain branches of mathematics.

Even if you're lucky enough to find a course that does teach you programming instead of computer science or discreet mathematics, in order to actually write anything that works there's a ton of arcane detail that you need to learn and there aren't many ways to do that other than dragging through tutorials, manuals, FAQ's and forums and other people's code by yourself. By the time you've done that it's not likely that your knowledge is going to be rounded, flexible and generally applicable. It's more likely that your knowledge is going to be, at least in some areas, brittle, specific and sketchy. So what are the chances that you're going to want someone to look at your code?

And maybe this is what is behind what seem like stubborn denials, refusals and condemnations of pair programming. When you suggest to someone that you write code with them and their response is "I taught myself to code, why should I be forced to do all the work for some rookie who can't be bothered to stay up nights himself," or even "I don't have to drink a bucket of vomit to know it's a bad idea." You might guess from the emotive reaction that there's fear involved. Perhaps the fear of the autodidact.

Try everything once...

This post has been bothering me for some time.

I was tempted to point out that programming simply isn't like walking down the street. Programming isn't a straight race. In programming: fast!=good. But then, when I thought about it some more I realised that programming in a team is in some ways like walking down a busy street: like it or not, the best way for anybody to make progress is to have some sensitivity for the speed at which others are moving. In both programming, and in walking down the street: fast!=good.

Finally I wondered who would want to hire, or be on a team with, the kind of person who can't even walk down the street without getting annoyed. But maybe behind all this maladroit bluster is fear. This is what Kent Beck has to say about fear in the preface to his book "Test Driven Development".

• Fear makes you tentative [and so reluctant to try something new - like pair programming?]
  


• Fear makes you want to communicate less [like maybe not wanting to pair program?]


• Fear makes you shy away from feedback [like maybe not wanting to pair program?]


• Fear makes you grumpy [like getting annoyed with people you don't know for walking down the street?]

But what are his fears? Are any of them legitimate? It might be legitimate to fear that pair programming will mean that you will have to spend your entire working day explaining to some newbie where to put the semi-colons. For this reasons pairs should be changed regularly. It might also be a legitimate fear that some of our best ideas and our best problems to solutions happen when we're alone. A way of working that allows people to cook up ideas in private before they test them out in public is well-known in other collaborative fields - the so-called "Cave and Commons" approach. For that reason, pairing shouldn't be scheduled to take up the whole day. Programmers should be give time in their "Caves" to get their heads together and sketch out ideas. A friend of mine who regularly paired with someone and didn't take this approach said that he and his partner found themselves coming in earlier and earlier each morning to try to sketch out their ideas and find a solution to the previous day's problems before their partner arrived.

Pair programming is about learning from other people and letting people learn from you. Pair programming is about sharing the knowledge of a system around a team. If you're really worried that you're not going to learn anything new when you pair with someone, don't be. Ask any teacher, they'll tell you that you only really understand something once you've taught it to someone else. And that's assuming that you manage to find someone who really can't teach you anything. Chances are they will know something you don't know. They'll know a library you don't know of, they'll have worked on a bit of the system that you don't know. They'll know a keyboard short-cut in Eclipse, or (may a higher power preserve us) in vi. They'll have been taught the latest template libraries in their final year at college.

There are lots of reasons why this is a good idea. If a member of the team leaves for some reason, it reduces the chances that some part of the system will become impossible to maintain . It increases the chance that mistakes and problems that require knowledge of the whole system will be spotted. But it's certain that pair programming won't work if it's forced on people.


Agile Lab's Technical Aspects of Agile course offers developers a chance to experience pair programming in a safe, non-threatening environment. At the same time they improve their technical skills in test-driven development and their coding and architectural skills through refactoring.

Technical Aspects of Agile - Central London 8th and 9th July

We're running a course on the Technical Aspects of Agile on 8th and 9th of July at 01Zero One in Soho, central London.

The course will run for two days. The first day will deal with test driven development (TDD) and the second day will deal with refactoring. Throughout the course people will be asked to pair program.

We understand that for various reasons people can find pair programming daunting. This is a perfect opportunity to give pair programming a try in a safe, non-judgemental environment. We think you'll like it.

Technical Aspects of Agile - Course in Development

We're thinking of running a one-day, actually possibly a two-day course that covers some of the crucial technical aspects of Agile. We would probably run this through 01 Zero One in central London, where we've already successfully run our introduction to Agile methods course. We would probably offer the course initially to people who are comfortable programming in Java, but we might also offer it for more web-based languages such as Flash, AJAX/Javascript or Ruby on Rails. Of course if any company wanted us to run the course in a particular language, we could talk to them about offering the course them in-house.

Pair Programming. To many people, especially in senior management, pair programming seems completely counter-intuitive. Surely, by getting two people to do the job of one person you're just halving your productivity? A substantial body of research shows quite the opposiste - that pair programming doesn't reduce productivity, but maintains productivity whilst substantially reducing the number of serious defects that are later found in the code. This course would cover the very good reasons for introducing pair programming and how to deal with some of the potential objections. It would also deal with how to start pair programming - what are the do's and don'ts and provide course participants with some hands-on experience of programming with other people.

Test Driven Development. The practice of writing a failing automatic test for each piece of software functionality that is added to a system, together with a script that can run all of these tests has many beneficial effects on the process of software development. This course would give participants experience of writing tests and then coding against them using a well-known testing framework such as JUnit.

Re-factoring. As software development progresses on a project, code gets messy and changes in one place cause unexpected breakages in overs. Re-factoring accepts the reality that code gets messy over time and builds on the advantages of TDD (test-driven development) to allow principled clean up of code. Course participants will be given a chance to clean up the kind of horridly entangled bits of code they might experience and be shown the possible benefits of re-factoring for the ongoing support of the codebase.