Teacup Programming

Teacup Programming is a variation on pair programming.

Why teacups? While sitting around a round table during a team retrospective where we had mentioned pair programming the conversation drifted a little when someone said it felt like we were sitting in a teacup ride or something.  Naturally, this led to combining the two ideas and teacup programming was born.

The idea is based on amusement park rides where the rider spins a wheel in the centre of the ride to increase the spinning velocity of the rider's individual car.  The most widely known example of this is the Teacup ride at Disneyland.


Requirements

• An even number of programmers 
• a table (round is preferred but not necessary and a rotating table is even better)
• one computer for every two programmers

Steps

1. Sit the programmers around the table with a computer in front of every other programmer.

table setup

2. Each programmer with a computer begins working with the programmer on his or her right.

pairs with person to the right

3. After a designated period of time, say 30 minutes, the pairs switch.  This is done by either rotating the table one spot to the right or having everyone move left one spot so the programmer on the right from each previous pair is now sitting in front of a computer.

rotate the table one spot

after rotation

4. Again, each programmer with a computer then begins pairing with the programmer on their right (this is a consistent rule for creating pairs) and the timer is reset for another 30 minutes.

again pair with person to the right

5. Goto 3.

The key point in this rotation system is to always have the one programmer from a previous pair remain working on the same computer and thus on the same problem to help reduce lost time due to context switching.  Also, everyone at the table gets a look at each problem which means more eyes looking at the code.  The drawback is that one programmer only ever works with two others at most.

Variant

programmers "leap-frog"

A variation to increase the number of pairing combinations is to have the person relinquishing control of a computer get up and "leap frog" positions one direction or another.  This adds more complication to the rotations but allows an individual to pair with more people in the group.

We have yet to actually try this out and so cannot say whether it is a viable technique or not but I think it does have some merit and there may even be some specific situations where it might be best applied such as at a hack-a-thon where there is a long list of problems or bugs trying to be solved none of which are too lengthy or difficult or for practicing for a programming contest where people are just trying to solve as many problems as possible.

If anyone gets around to actually attempting this please post a comment with the results.

Is the industry moving away from Agile?

I don't think so.

I'm writing this in response to a link to this article on slashdot that a friend sent me asking the question which I've used as the title for this post. (The slashdot article references this blog post which is a good and informative read in itself and I found I agreed with many of his points. What starts as an emotional rant turns into a very well presented article.)

There isn't just one way of doing development or just one way of doing agile; hence the name agile. I thought the first poster on slashdot hit it on the head especially with his comments about having the right people and making adaptations to your business.

The author leads into the article complaining about agile but later talks about how many other methodologies can also be successful. The important thing in my mind is picking the right approach for the job (or team even; some methodologies only work with a certain type of people) and also understanding that methodology properly. In fact, the understanding must come first to be sure that you do pick the right approach for your team/project.

The author made a good point about how some people use the words "agile" and "scrum" interchangeably. It is my opinion that these are the teams that fail at agile. It could be that some see agile as being less structured and as a result end up thinking there are fewer rules and less accountability. An agile approach may give the developers more leeway and freedom but with that comes more responsibility. My experience has shown that a junior team usually cannot succeed in these circumstances. They typically will not have the experience required to make the design and implementation decisions that are usually made by someone else in a different model. It's been a challenge to overcome with some of our teams.

We use SCRUM outwardly but also take the XP approach mentioned by Kent Beck in "Extreme Programming Explained" and implement changes slowly. We reflect each week in our sprint retrospective on how those changes helped/hindered us and we also talk about new ideas and ways to improve our process. Yes, we follow a scrum model but one that we have adapted to our needs. We also know that it is more than just doing this list of things and then we'll have it right. We know that the business needs change, the business itself changes and that we need to be able to change and adapt in order to keep pace. I feel that with the right mix of people and support from management agile can be very effective.

Although we don't do game development where I work, I had previously found this pdf about lessons learned implementing SCRUM at Bioware and one of the key things I took from that was that they also ended up adapting SCRUM to their own needs. I think this is key to success with any methodology; being able to take what works and adapt where you need to.

TDD Adoption

I've been doing a lot of reading about Test Driven Development and how to use and apply it and found some of the most revealing material while reading about Behaviour Driven Development. I was reading this Introduction to BDD and the TDD Adoption Profile mentioned at the top of the article was the catalyst for this post. This will make sense to anyone who knows anything about BDD since BDD is basically an attempt to relabel TDD to help people use it more appropriately.

What I hope to do here is highlight some of the key areas that seem to cause developers to fail while using TDD or fail to adopt TDD. I get the impression that development teams attempting TDD often end up not using it properly or consistently or else quitting.

Developer Buy In

This could be a failing point of any development technique but I think it affects TDD more so because of the requirement to write tests first. If the developers don't buy in, they won't write tests and will continue to just develop in whatever way they are accustomed to.

Focus on Testing

Of course there is a focus on testing in TDD! The T stands for Test, doesn't it? This was one of the biggest realizations for me while reading the BDD Introduction mentioned above. They mentioned that most developers get to step 4 in the TDD adoption profile and stop there missing the benefits of steps 5-7. I think this was a big realization for me since I was probably still at step 4 in my own acceptance of TDD. After reading steps 5, 6 and 7 and reading about how BDD is basically TDD with less focus on testing and instead a focus on behaviour I began to see the real benefits of TDD. So to oversimplify things, the BDD folks are basically rebranding TDD to focus attention where the the real gains in TDD can be made. This leads me to wonder then if a developer would gain more by first being taught about TDD with this emphasis in mind rather than having to get there on his own, making these realizations as he goes. I can see how the personal realizations would carry more weight than just being told about these things in advance but wouldn't foreknowledge at least increase the likelihood of the realizations occurring?

Learning TDD on the Wrong Project
I don't mean to suggest that TDD only works with certain types of projects but I'm convinced that there will be a greater chance of adoption if the selected project is a new one or has had very little work done on it. The reason I say this is because the first step in TDD is to write tests first and not to write code you don't have to. So writing tests for existing code can at times seem pointless or at least more work than it's worth when you already have a working application (although there is merit in having thorough unit test coverage) and writing tests for new code requires the team to develop using new techniques on an application they've likely already spent a lot of time on and are fairly adept at debugging. I'm not suggesting Unit tests shouldn't be written or that TDD can't be used on an existing project, I'm just pointing out areas where I have seen resistance to TDD adoption. For a team new to TDD it may be better to start fresh. Starting fresh may also help the team feel more inclined to experiment with this new method whereas an existing project will already have set expectations the team is accustomed to. I appreciate that step 1 in the TDD adoption profile is about starting by writing unit tests around their code so perhaps a first foray into TDD is best done on an existing project but I would argue that it would be better to not refer to it as TDD at this point in time because it is actually not yet TDD. Instead I would call it what it is and that is writing unit tests to help improve the quality of the code being tested. It is not yet TDD because TDD requires that you first add a test for the feature you want to add and then after seeing the test fail you implement the feature.

Poorly Designed Code is Hard to Test

One of the realizations while learning TDD occurs when the developer discovers that TDD is in fact a design process that helps them define the application's API. Developing in this way will likely produce better code than was previously being produced and of course have tests written for but my point here is that if attention is also given to applying best practices like proper object oriented techniques and design patterns then TDD adoption is smoother and the TDD process itself becomes easier. Take MVC for example. When followed correctly all business logic should end up in the Model which makes things much easier to test, especially if the model was created using object oriented design principles.

I know some of what I've said are problems that are addressed by using TDD and in realizing that it hopefully increases the value of TDD in the eyes of those trying to use it.

Kent Beck has written a great book called Test-Driven Development: by Example that I would recommend as a great starting point for anyone trying to learn TDD.

Some might ask, why not just use BDD? My response at this point would be, I don't know, why not? Perhaps frameworks for BDD are not yet as established as those used in TDD. Maybe we should all switch to BDD. Or maybe, TDD works just fine provided we shed light on more than just the testing aspect of it.