Nominees:

(in strict alphabetical order)

AXI

LogicaCMG

Oracle

JavaPolis RAD Race 2005 - Overview & Winners

This year's edition was an all-time first on JavaPolis. And a try-out edition too; because it takes a lot of guts to program for 12 hours while other people are attending the JavaPolis convention. The JavaPolis RAD Race is a shortened version of the "full" Original RAD Race" in which Java and non-Java teams compete without limitations towards the tools/frameworks/languages/etc. that are being used.

The assignment was a (partial) re-adaptation of an earlier "full" RAD Race case but with a slightly adapted data model and less (=16) than the original 25 deliverables. The RAD Race focuses on delivering real-life functionality. It is not an architecture or algorithm development contest.

The JavaPolis RAD Race 2005 case was about a JUIdicial Universal Insurance Claim Engine (“JUICE”). The 19 pages assignment gave the specific details to build this system. Additional questions by the teams were answered publicly; so that every team worked on the assignment from tjhe same point of view. The following is a high-level, summary view of JUICE:

• Every person living in the BENELUX is part of JUICE and pays an annual fee to cover for the costs of JUICE.
• As soon as a person becomes a party in any case of law, he/she has to choose a lawyer from a pool of available lawyers. The choice of lawyers is restricted because each lawyer has a different specialization and seniority, that must be matched against the type of litigation/case/court.
• A law case is based on submissions (or documents) which originate from parties involved in the case, for example lawyers, experts or the police, etc…
• All submissions are logged into JUICE. Creating submissions (for example a pleading note made by a lawyer) costs money. The person involved in the law case must pay his lawyer for the effort of making this submission.
• This cost is logged into JUICE, who will pay back these costs if a number of strict conditions are met. However, JUICE will never make a full refund for the whole cost; refunding is always partial.
• By (partially) paying back the costs that were made, EUGOV wants to emphasize that going to court is a basic civilian right for all, rich and poor.

Ultimately, of the 15 registered teams, 11 showed up at the start at 08.00 Hrs with their individual toolset. The simple fact that they took the challenge makes them winners because the RAD Race is challenging exercise, benchmark and test environment for development strategies and toolsets.

List of the teams with the toolset they used

After a very long (Tues)day of programming and several refills (sandwiches, soft drinks and enormous quantities of pizza - courtesy the JavaPolis organization); all machinery was tightly locked up and the RAD Race room returned to silence at around 21.30 Hrs. The jury started screening the teams at 09.00 Hrs the next day. A standard jury script is worked through. In this, the jury checks the self evaluation form in which each participating team states its level of realization of the assignment. The jury places itself in the position of a new user, who will (try to) undertake obvious actions. As a individual, a new law case is started in JUICE and subsequently worked out with the choice of a lawyer; submission of documents and so forth.

For a lot of teams, the data (provided on CD-ROM) import proved to be a serious and underestimated problem.

iSenciaSQL was one of those teams, but they were also the first to admit that they should have known, since this was clearly announced on the JavaPolis RAD Race information page. As such, a real life situation usually means real-life data, gathered from an earlier application; and tools for doing this should be in any toolkit, was the unanimous opinion of the jury. A lesson learned; the iSenciaSQL team announced on the spot that they would be updating their framework accordingly. Likewise, PearlChain lost a lot of time with the data, but they produced some very nice query interface screens.

Quixiz had no problem with the data; they had a very good view on the case and achieved the JUICE global risk calculation very well but ran in to problems with some web service technicalities when passing a series of data instead of 1 parameter. The "Team With No Name", despite their name, acted as a real team because they knew each other from earlier work experiences in high pressure (banking) environments. Nevertheless they were accorded the "Bad Luck" prize: until moments before the start of the demo, everything seemed to function and then suddenly fell apart because of a corrupt file system. The jury had to move on, as they did for 2 teams that gave up earlier.

The AXA team was an interesting case because AXA is not a software development company but a ...bank! 2 guys that wanted to test their (internal) development toolkits against the professionals: that is the real RAD Race spirit. A nice story and a nice GUI; one of the only teams that realized a "role based log-in" but alas with not enough overall functionality finished.

BLISS was a strong working team, until half of the team was called back to Danmark for urgent business. The other half of the team promptly took up to challenge to continue the competition; the "Prize for Best Sports" found a good home and BLISS was promised a revenge next year.

Oracle obviously did not have any problems at all with the data, it was (quote) "...done in 15 seconds (flat)...!" They produced a unified people view (judges - persons - lawyers); the risk calculation worked very well; no other features than standard SQL were used and the existing front-end portion of the application was OK. Nevertheless, some things crashed but were recovered swiftly during the demo.

LogicaCMG proved to be very good in datamanipulation and e-mail integration. They had a very good view on the JUICE application because they took the time for an in-depth analysis. The team produced a very good working web service and were the only team to have a "JUICE document submissions" working; using the database a storage. Time was too short for even more functionality.

The AXI team got their data model quite right after some "pushing & bending" in the tool. They also had their web service working very well. The same applied for the embedded e-mail functionality in the JUICE case, that was used throughout the case to communicate with parties involved.

No team was able to finish the JUICE application.

After careful deliberation, the jury decided that 3 teams got very far in analyzing and developing the requested functionality in a stable and functional way and were effectively using the provided data when demonstrating their application. As such, there was no overall "winner"; 3 nominees were identified.

These nominees were announced at the Keynote speech on Dec. 15th 2005; no difference in classification was made between these teams. They are listed here in strict alphabetical order:

The RAD Race - once again - proved to be a serious test for application developers. But interpersonal and teams skills are equally important, in combination with in-depth knowledge of a complete toolset. Interestingly enough, it was only after the jury deliberation that it was noted that 1/all 3 nominees used Oracle tools to some extent and 2/had a lot of field experience. The JavaPolis RAD Race was also a setting were teams competed primarily against themselves and as such less against "the others". Very much as in golf: you try to improve constantly, resulting in a great learning experience. Were a great game is more important than a game won.

Food for thought, and definitely a challenge to other tools/frameworks/environments/IDE's/..
Will we see them next year? Or will we see other teams participating in the "full blown" RAD Race, competing against non-Java teams. Taking up the challenge against 4GL's, code generators, .NET environments, etc. ?
The competition is open!