Friday, November 28, 2008

Smalltalks 2008 Coding Contest writeup

As in other years, this Smalltalk coding contest consisted of writing a program that would play a game. The ranking of each player was determined by comparing their corresponding scores in the game. The qualifier round, held before the conference, serves the purpose of bringing all the contestants to more or less the same level of proficiency, i.e.: they all have a program that plays and obtains some score. The finals changes the rules of the game the participants have to play, but the nature of the changes is not communicated to them. It is up to those competing for a prize to determine what has changed, how to adapt their program to the perceived changes, and to do so under time pressure. The idea of having to make changes within something like two hours is that, if a program is well designed, then changing it will not require an extraordinary amount of time and effort. If, on the other hand, a participant comes to the final round with a program that is too tightly coupled with the problem at hand, then changing it will be costly. It is assumed that since business requirements change continuously in real life, this way of measuring the quality of a contestant's submission is appropriate.

The problem for the Smalltalks 2008 Coding Contest was again to play a game. The particular game was defined in terms of what happens in a software development team. In other words, participants would have to create a program that would behave like a software developer in a game in which an application is being built. Some of the factors that contestants had to keep in mind are things that we all know very well. For example, a little stress is a good thing because it may give us a sense of urgency that may allow us to finish our tasks quicker. On the other hand, too much stress will eat into our productivity, and no matter how much we work we will not make much progress.

Moreover, interaction with other team members is a key factor for a project's success. Because of this, the game gave an advantage to those players that collaborate with each other by making it less likely that completed work units would cause bugs when integrated into the final delivery. However, this is not so easy to achieve all the time. It is for this reason that the game came with six autonomous players with different personalities, in order to stress the capabilities and flexibility of each of the competing programs. The autonomous players were played by the game server itself, and so the contestants did not have control over who they had to play with in a particular game.

In order to make it interesting and politically correct, the autonomous players were modeled after six Dilbert characters: Dilbert, Alice, Asok, Dogbert, Ratbert and Wally (which finally explains this earlier post). The implementation of the game itself was rich enough so that it was possible to implement a single strategy shared by all these different characters. What made Dilbert different from Dogbert was a personality object that provided 17 tuning parameters for aspects such as the amount of stress the player would tolerate, how much work it would be willing to accept at any one time, and so on.

Something that was also modeled was how quickly players would behave in a counterproductive way as a means to retaliate for their perception of lack of collaboration by other players. For example, Dogbert is not usually very willing to help others. Since it is in his personality to put himself first, he may decide to simply accept work from others to just delete it and thus get rid of it. He does not care about the consequences of this, because he will delete this work as long as the boss does not assign it to him in the first place. What happens then is that if Dogbert deletes work sent by Alice, the boss will complain to Alice for letting work drop on the floor. This increases Alice's stress, so it is in her best interest to note that the behavior complaint was related to a work unit sent to Dogbert. In turn, this will make it less likely for Alice to ask Dogbert for help later on in the project.

Contestants had to deal with this counterproductive behavior as well. However, they were not told which player had which personality. All they saw were developers called names such as Smith, Jones, or Taylor. Part of the challenge was to make programs that would learn from their experience as projects progressed to completion.

You can see the official rules and qualifier server for the contest by selecting the coding contest section on the left here.

The winners of this year's contest were Guillermo Amaral and Guido Chari. The second best score was obtained by Hernan Wilkinson, one of the organizers. Unfortunately for Hernan, he was barred from receiving prizes at the finals. Diego Geffner finished in third place at the final round. Prizes included an iPod Touch for each of the winners, courtesy of Instantiations and Caesar Systems. Diego Geffner obtained an MP4 player courtesy of GeoAgris. Snoop Consulting also provided bookstore gift cards.

No comments: