Team programming

[Alessandro Scotti]

Hi all,
I don't think I am the only one to feel that programming a chess engine can be, at times, a very frustrating task... why, recently even an outstanding name like Ed Shroeder is having a bad moment because of a bug!
In those times, posting in forums or exchanging emails may be good, bu tit's still different from having someone else that care about the engine just as much as you do...
Of course, the same is true when the engine improves and grows stronger and you'd like to share the joy with someone!
On the other side, having more people working on the same engine could be extremely productive from a technical standpoint. Ideas will be flowing much faster and it is also possible to "specialize" on some parts of the engine, so getting more experience and knowledge in selected areas.
And I've just outlined just a few items, there could be much more (also on the negative side) but you get the idea.
One example that comes to mind is Spike, which has grown very strong in a relatively short time... I for once would be very interested in knowing more about the teamwork that's behind this great engine, even more than its technical details. Maybe Daniel could do an interview?
So my question is: have you considered joining forces when working on a chess engine, and if so what do you think would be the ideal team?
Up to a while ago, I thought of my own engine as a "personal" accomplishment and would have answered "no". But in the last couple of months or so I've been pondering the question some more and now I'm not so sure...

[David Weller]

Hi Alessandro,

Testing is so time consuming, that, a good 'team' could be N programmers M Chess Pros, and 10*M*N testers

If you didnt have to test anything, your programming load would probably seem/be much lighter ...

I would be interested to know how this might be coordinated

David

[Dann Corbit]

Pair programming is one of the really good ideas from extreme programming. I think for the best results, your collaborator should sit right beside you.

[Daniel Mehrmann]

Hi all,
I don't think I am the only one to feel that programming a chess engine can be, at times, a very frustrating task... why, recently even an outstanding name like Ed Shroeder is having a bad moment because of a bug!
In those times, posting in forums or exchanging emails may be good, bu tit's still different from having someone else that care about the engine just as much as you do...
Of course, the same is true when the engine improves and grows stronger and you'd like to share the joy with someone!
On the other side, having more people working on the same engine could be extremely productive from a technical standpoint. Ideas will be flowing much faster and it is also possible to "specialize" on some parts of the engine, so getting more experience and knowledge in selected areas.
And I've just outlined just a few items, there could be much more (also on the negative side) but you get the idea.
One example that comes to mind is Spike, which has grown very strong in a relatively short time... I for once would be very interested in knowing more about the teamwork that's behind this great engine, even more than its technical details. Maybe Daniel could do an interview?
So my question is: have you considered joining forces when working on a chess engine, and if so what do you think would be the ideal team?
Up to a while ago, I thought of my own engine as a "personal" accomplishment and would have answered "no". But in the last couple of months or so I've been pondering the question some more and now I'm not so sure...

Leo interviewed the Spike team allready for CVSN May he wants make it public ?

Best,
Daniel

[Anonymous]

I think coordination is possible. The internet offers many way to work on a problem (be it a program or something else).

All you gotta do is really do it and not only talking about However i can understand that some guys might have problems with that. If a team of say 4 or 5 guys work on a program together one might feel "hey this guy can see my code ... gnaahh i don't want that". If many peeps work together this means sharing ones skills and talents , too. So others can see your tricks... maybe this is why many peeps talk about it but noone actually makes it. If you know the guy personally, cuz he's living around the corner that is easier i think ... !??!

All you need is:

-A project manager
Usually this guy is not an expert in programming. He just needs to know a little bit about everything. He needs to know basic programming , basic chess and ... he needs to know how to make a plan with milestones, he needs to define goals.

-programmer(s)
One guy working on this, the otehr on that.

-tester(s)
Making enginematches and running testsuits.

Flow of Information:
Email exchange between the programmers and the manager. Every line of code is being spread , otherwise programmer A does not know what programmer B does. And Manager C does not know how far the current stage of the project is if he gets no information
After exchanging emails on a daily basis , a tool like teamspeak ist used to do small comferences and talk things over. At a later stage , when an engine that plays chess is done, the testers get int and run their thing. It's important that they run some sort of "standard tests" to really see improvements ... you can't see improvements if you run different tests everytime eh?

That's all you need. Oh .. yeah ... and again you gotta trust the others a lil bit and should not hold back anything.

Cheers

[Volker Böhm]

There are interviews on how we organize spike programming, for example somewhere in the arena web pages.

But for short here:

Ralf and me haven?t got much time to program thus we didn?t expect to get a good chess engine of our own. When doing it together it is more fun and less work (sounds good doesn?t it?).
It was easy to work together as we are good friends for a very long time. Here is how we devided our job:

Programming:
Ralf: Evaluation
Me(Volker): Interface, Search, Basic-Datastructures, Pruning

1. Rule: We are doing what we like to do. If anybody would like to add some code in the "others" aerea it?s ok. Just send the change to the partner.
2. Rule: Explain what you are doing and what you have done. Even if not expecially in your own code.
3. Rule: If ever you have an idea for the "others" code, tell him!
4. Rule: Don?t change anything that is not tested enough.
5. Rule: Add integration hours where you put your code together and get a new release.

Any more questions?

Greetings Volker

[Roger Brown]

Hello Volker,

I have a question....

Would you say that your friendship and fun approach to the task made it bearable to program Spike as a team?

Would that be a critical element?

I am asking because your reply seems devoid of technical details and more a focus on intangibles...which I find fascinating.

Oh, thanks for Spike!

Later.

[Volker Böhm]

I think it is technical easy to distibute chess programming. The only thing that may not easily distributed is the basic data structure and basic methods (board representation, move generator, ...). Once you have that piece of code fixed and good working it is easy to seperate all other tasks.

As both of us are programming just for fun with little time it is neccessary to keep a good mood. There are many opportunities to dispute while programming or playing in tournaments.
IMHO the most important thing is to keep it fun for all participants and to allways find good trade-offs.

Greetings Volker

[Pradu]

...There are many opportunities to dispute while programming or playing in tournaments...
Greetings Volker

Disputes create serious problems for team programming in computer chess. Picking a partner who thinks exactly like you isn't good for team programming either.

[Volker Böhm]

That?s true. It is the ability for compromise that is important.