RobocodeFeedback

The RoboCode workshop in XpDay2 was excellent. Everyone could see that there were some problems with various things, but despite that (because of that?) it was great.

(Response to these points and a summary at the bottom)

• Problems with the network

Perhaps these problems were caused by the rented laptops, or the rush to set everything up in time, or whatever. It got done though, and productivity wasn't hurt significantly.

Was team 1 the last to connect to the repository? Certainly among the last. This inspired some panic, but given the aim of the session this may not be a bad thing.

• Problems with Eclipse, CVS, the trackpad, the keyboard...

At the time I said the session was a terrible advert for Eclipse, and the confusing GUI wrapper to CVS could give CVS a bad name. However this probably isn't very fair since one doesn't normally pick up a new IDE just before running headlong into important deadlines.

These problems could be made to go away by allowing and suggesting that team members bring a laptop configured with an environment of their choice. CVS is a convenient standard interface to the automatic arena and scoring system... presumably teams would be limited to two laptops anyway.

Bringing in personal work environments may throw up new and exciting PairProgramming issues.

• "Hands up those who have used JUnit before"

Splitting teams up so that most had at least one person familiar with each of Eclipse, JUnit and CVS was helpful. Suggesting that players become familiar with these before joining the session might have been helpful, but I think it could also detract from the experience.

The pathological case is a team who have already written and honed their RoboCode, and turn up on the day ready to regurgitate something they know will work.

...more to follow later. WikiWritersDontGetPaid?. -- mca

I enjoyed the Robocode workshop a great deal. Well done to the presenters. In the workshop we used mock objects to test the robots, this was designed to give us confidence in our robots. Unfortunatley the supplied Mocks did not allow us to do many meaningful tests so even if we had a green bar, the robot would often go off and behave in totally unexpected ways.

After the workshop it occured to me that perhaps what we needed was not a MockBody object but a SimulatedBody? instead. This would allow a test like this:

public void testRotateTowardsWall() { SimulatedBody? body = new SimulatedBody?(); body.setLocation(100,100); body.setHeading(40);

brain.rotateTowardsWall();

assertEquals( 0, body.heading() ); }

-- BenHogan -- nice idea Ben, thanks -- PaulS

Well, let me start by saying that the feedback for the RoboCode workshop has been excellent, despite the fact that it was very experimental. I've learned a lot from doing it, and I'm glad to hear that a lot of the participants feel the same. Thanks for the feedback!

I can respond to some of the comments made, and give a little detail about the results.

Network problems was the thing I was most worried about - with good reason as it turned out! It's always difficult to get a lot of machines with various weird configurations to talk to each other on short notice. I don't know what can be done about this other than to try to ensure that when we run it again we do so on a network that has been preconfigured. I can't thank Paul Nasrat enough for the huge effort he put into getting the network up and running under tough circumstances!

Interestingly enough, although team 1 was probably the last to successfully connect to the repository, they went on to use it to greatest effect. This team integrated their code (joint) most often (only team 4 did as many integrations). Despite the lack of testing (only 2 commits - an eternity in XP hell for you guys) this serves to prove one of the points I was most interested in demonstrating with this workshop - that disciplined use of continuous integration can enable you to develop better, even in the absence of other practices.

Team 1 themselves thought they'd got to the point where they were afraid to make any changes, and with perhaps another hour of workshop time might have lost their lead. It would be nice to see whether that comes out next time we run the workshop.

Team 4 were joint highest integrators and did a good job of testing. Yes! For every code commit, tests were committed as well! This team actually did very well and probably deserved a higher score. They were very unlucky that they hit a Robocode null pointer bug right at the point where we switched over to 2 battles per iteration, losing many points in one go. Sadly, that's life in the evil world of automated game-runners, and there was little we poor humans could do to even the score.

Overall, everyone did an excellent job and seemed to be very engaged by the workshop. Every team integrated their code approximately every round or more often and 2 teams did pretty extensive testing despite the problems.

It was a great moment for me when all the teams rushed to the front to watch the battle and then ran off to carry on coding, ignoring me and Paul and trampling over our crushed and bleeding bodies to get back to their code!

Regarding the tools, we needed something decent and free, and Eclipse is very good in both respects. I don't agree that the CVS integration is poor. I think it's very good, and helps people with relatively little revision control experience understand what's going on. The main problem with it is the bizarre way it refuses to maximize the integration view, stuffing it down at the bottom of the screen. At least one team I saw got caught out by that, and had an unfinished integration hanging around at the bottom of their IDE. This is an Eclipse misfeature. I've had some success setting the integration view to "Fast View" mode, and resizing it to take most of the screen. Then it pops up conspicuously when needed.

As to people bringing along their own laptops with their favourite IDEs, I don't think this would work all that well. The problem is configuration issues. I've worked with teams before where everyone used the same IDE but configures it slightly differently. A lot of time got chewed up messing with or being confused by configurations that could have been devoted to programming. Ben is right that pair programming issues do surface here, but they're mostly annoying avoidable ones, not proper things you could learn from. It's something I'd prefer to avoid, even if it means people using IDEs they're not 100% familiar with.

One of my goals for the workshop was to put people under some pressure and get them to use revision control for real. Too many teams treat it as a handy place to stuff the code after it's been delivered. I'm glad people learned about this, even if it was the hard way! So I'm unrepentant on the tools issue!

Ok, on to testing. I think the comments that unit testing didn't work too well are entirely well-founded. The only trouble is, I don't really know what to do about it. I know what I'd *like* to do, which is strip out Robocode for a client-side functional/system testing environment. That would give teams a chance to try out the "physics" of their robots, as in Ben's SimulatedBody?. I don't really want to encourage people to do their testing by eye, which is manual testing, so I'm not quite sure how we'd verify test outcomes automatically. Maybe SimulatedBody? attacks this at the right level. The real problem here is that despite a couple of years of "coming soon" promises, Robocode is not open source. Probably the best alternatives are to find another environment or roll our own.

As to the green bar not giving confidence in what the robot would do, I think part of the issue (aside from the physics issue covered previously) is that it's actually pretty difficult to predict what a robot will do in a continuously changing environment. This is really one of the major cornerstones of the workshop: you may think you can predict and plan for everything up front, but in reality you have to do something simple and give it a go to see what happens - often in real life this is going to happen in a production or semi-production environment. You *can* write tests for what your robot will do when it gets penned in a corner and shot up, but you often won't foresee the circumstances until they happen. This is a lesson in incremental development.

External customers. We thought about this one for quite a while, and we did originally envisage having a separate role. The problem we predicted (and which I think would have turned out to be real) is that there would be too little for the customer to do to justify their time. We saw in the workshop that everybody wanted to see what happened in the game, and discuss new tactics in the team. It may be that we could try the idea of having the game run continuously and then a separate customer would be justified. Personally, I can't help feeling this might detract a little from the punchy nature of the workshop, but might on the other hand serve to make it more realistic. Dafydd made a good point about the need for stealth workshops that trick people into avoiding management briefings and getting stuck in - maybe the customer role would help attract such people? To be decided....

So, to summarise: this workshop wasn't meant to give you a warm fuzzy feeling about XP, it was meant to make you need a beer and say to yourself "Thank God that's over", but maybe also feel strangely elated. And we made some mistakes, but I can promise you this: it'll be back, and it'll be better!

DuncanPierce

Yes, thanks to everyone who attended. I'm not sure we made it clear it was experimental, but we've had a lot of constructive ideas to improve the session so I take from this that attendees were happy to accept the rough edges. One thought is to use ant instead of rely on the Eclipse CVS integration - this would allow any IDEs to work, or even just notepad.

Keep the feedback rolling,

PaulSimmons