When I was a child, I remember the unfathomable boredom of Judo competitions. We left house early in the morning to be on time for the weigh-in which could last an hour, then waited an additional hour to allows organizers to divide us into pools and finally display the approximate schedule for the day. Passing sooner or later had no importance since the medal ceremony would be at the very end. In my memories, a judo competition was just a noisy boring day.

Then, some clubs decided to give medals as pools’ results arise; we then went to the podium as soon as our fights were over and could then go back home. At the very end of the 20th century, believe me, it was such an innovation and generate lots of frictions. The parents loved the concept, the refreshment bar a little less so (but we were too poor to buy anything anyway). We still had to go to the morning weigh-in but we no longer had to stay until the very end.

What was my surprise when my children participated in their first competition; what changes in 20 years… The weigh-in is done by the master during training the week before the competition and the times are announced a month in advance. All you have to do is arrive at the scheduled time, give your name at the entrance, participate in the common warm-up then the pools start and the medals are given as soon as a pools finishes. On average, it takes an hour.

Do you realize ? We have divided the boredom time by a factor of 10 in less than 20 years!

But sometimes the competition misfires. Registration is laborious and a long queue forms at the dojo’s entrance. Either the pools are unbalanced; instead of 4 judokas (6 fights), we can have pools of 6 (fifteen fights). Each category can then fall behind schedule which can accumulate and unlucky parents must stay an hour and a half instead of an hour.

Personally, I compare this hour and a half versus my childhood’s boring day and find it still satisfying. But most parents do not have, or no longer have, these references and compare with other competitions where they only had to stay an hour max. In short, it’s a bit of a shame for the organizers.

To avoid this pitfall for our next competition we organize ourselves, one of the parents suggested the common sense idea that everyone had the last time a competition “went out of control”:

We sould computerize this all: a CTRL+F in a spreadsheet and that’s it!

Captain O’ Bvious

Si simple! When a child arrives, he says his name, we search the table, we set a field’s value to 1 and we print the pools sheets. There must be some little black magic in between, but it must be simple for any average programmers?

And I said “no.”

Computer version

The big problem when we want to “computerize this all” is that we only see the tip of the iceberg and we forget all these things that go into “this all”, and all the others that are necessary to “computerize”.

This all

Since we are organizing a small competition, we will remain modest and aim for the Minimum Viable Product: we will only manage registrations and the allocation of pools. That’s all. Even if we are itchy, we are not going to computerize the timer, the scores, the order of the fights, the allocation of pools to the tables, the rankings and the all the rest.

We will therefore need a database to store the data. For each participant, we need their first and last names, gender, year of birth, weight and club. We will assign it a pool number, which will be sufficient and allows us to use only one table for all the data. There may be new columns to add but we will see that as we go along.

But as a result, you held personal data (first and last name). You understand that you are responsible for the data and must provide the right to access, rectify and delete the data. And since we have the year of birth and the weight, we have health data and a reinforced security obligation. Yes, all that GDPR stuffs…

If you want to use a web application to manage registrations by teachers, you will need to add user management so that they can list their registrations, modify their errors and remove children. Therefore, you also need to add access rights. And also be able to deactivate this site before the start of the competition otherwise it will be a mess.

In all cases, the organizers on site must be able to check-in those present (the famous “CTRL+F”) but also add latecomers and fix typos in all fields because there will be errors during registrations (believe me).

Concerning search, as it is not always obvious how a first or last name is spelled, this function should ideally also search for close matches. It would be a big waste of time if we had to ask each child to spell their first and last name. Also provide a “cancel” function because in the heat of the action, you may have checked-in the wrong judoka.

You then need a button to spread children into pools and then print the pools’ sheets. This is where it gets really fun because you don’t just make pools just anyhow. Here are the criteria to take into account:

• The pools are ideally made of 4 fighters (for 6 fights). But as we know that this is not always possible, we can make groups of 3 (3 fights) or 5 (10 fights but we prefer to avoid). If we really are in trouble, we can tolerate groups of 2 (they meet several times otherwise they would have come for nothing) or 6 (15 fights but the competition will last twice the time).
• Children are grouped by official age category or by year of birth (for youngest ones, depend on the organizers). But you can upgrade a judoka to a higher age category. If he is too heavy and/or too strong for his peers of his age it is not interesting for anyone so we let him go and face those in the higher category. For this, you need to know it and have the teacher authorization. Idem we can also downgrade for those who are too light and/or beginners.
• Pools are gendered; there are for boys and for girls. If needed, we can have a few mixed pools. The gender difference is not very significant among the youngest. Then it’s like for the age category, it can sometimes make the fights more interesting for everyone and you have to see that with the teachers (sometimes they are the ones who ask for it, so you will have to add a “mixed” column to know if it is requested, acceptable or not).
• A pool groups together children of similar weight. Not necessarily identical (two kilograms is not a problem) but not too far apart either so as not to unbalance the fights. We do not use official weight categories because we prefer that a heavyweight from one category can meet the lightweight from the category above if they are close enough. There are also exceptions, mainly lighter ones upgraded to heavier ones because they have experience or need a tougher challenge (the teacher will tell you).
• Judokas from the same club should not compete against each other. The children are there to confront opponents they do not know. But as this is not always possible, it is not dramatic if there are several from the same club.

You then have to be able to encode all kinds of arbitrary and improvised constraints. Like these two cousins whose families can’t meet each other peacefully and it would be better to avoid them crossing each other in the stands. They are the same age and weight. No luck, they are the two lightest in their category. One can go with the three other lighter ones but then the difference is too big… We can put the other with boys of the same age (she is combative, it could suit her) or with younger girls who have its weight (and as it is another time schedule the families will not cross)…

I made some prototypes in constraint logic programming (in Answer Set Programming if you want to know everything) and I never managed to obtain a satisfying solution. Either I have a few rare pools that go wrong because an important constraint is not respected. Either I authorize exceptions but the system abuses them and generates too many exceptional pools (and not always happy ones either). It may be possible, with time, to obtain a satisfactory program, but my intuition is that the constraints are not comparable to each other and cannot be combined to produce a single score to be minimized.

But let’s be optimistic and imagine that these constraints are not a problem. Let’s also admit that it will be easy to interface the spreadsheet with a constraint logic system (or for the more optimistic, to code an equivalent in their preferred language).

Do you accept latecomers? It happens all the time for a whole bunch of reasons and it’s a shame to tell a motivated child who has traveled miles to come that he must go back because he’s late (while pools in his category don’t have yet started). The program will therefore need to know the status of the pools (waiting, in progress, completed) to be able to add a latecomer. Preferably in a waiting pool, otherwise one in progress (but you have to know where it is fighting). And arbitrate the priority of this new constraint and the old ones…

And so far, we’ve only scratched the surface. By implementing a first prototype, you will realize that there are a lot of details to specify. For example, does the authentication use a pseudonym or an email address? do you allow a password recovery form? How does the search function really work to validate the registration of a judoka? What are the relative priorities of the criteria for the pools? And I’m not even talking about user feedback when they test your version 1…

Computerize

Even if it is for a small competition, we want to avoid misfire with the registration and distribution of pools so as not to be ashamed in front of parents and other clubs. We hope that by computerizing we save time, we will accept if we do not really gain any but we cannot bear to lose any.

The issue is much worse than compensation, it is honor that is at stake. Unlike an IT development company which will stipulate in the contract an “obligation of means” and will be able to take out insurance to cover damages “up to the price of the license”. As unpaid volunteers we have a tacit obligation to achieve results.

Performance side. I must now admit to you that what will take the most time once we have computerized all of this is to take the identity of the children. When he arrives at the table and we ask for his name, the ambient noise and his unsure diction force you to try several times to get a rough idea of the spelling of the name and first name. And that’s what generates the queues that we want to avoid.

We will therefore have to parallelize this step and have several people to do the check-in. Each equipped with a computer (or a tablet or other) containing our application. And the easiest way for these applications to synchronize is to distribute the application across a central server and several clients. In all cases it will be necessary to set up a computer network.

Efficience side. It is inconceivable that the system would suffer from the slightest failure; whether it’s a bug or a crash. Because if that happens, we will lose a lot of time and may have to restart the work by hand.

To avoid software bugs, you’ll have to develop like pros. With batteries of unit tests, integration tests and recipes with volunteers to check that the tool works on their equipment (and that they are able to use it) and with the teacher to check that the pools respect its criteria (notice we also need representative test data…).

To avoid network bugs, there must be an on-site network administrator who installs and checks the equipment before the start of the competition and is available to quickly fix any errors caused by equipment that has lost its configuration. I consider that all the equipment is on site to avoid depending on any Internet access.

To avoid crashes, redundant hardware is required. Whether it is the computers used by people, the printers but also the server which must be able to withstand a failure (i.e. a hard drive or RAM breaks). In the event of a breakdown, you must be able to reassemble the system in less than 3 minutes. I would almost go as far as putting two servers as master/slave to be able to switch from one to the other (but that requires more design and test efforts…).

What remains are the electrical outages. It would be bad but it can happen… Bring a generator?

Plan B. And as you are certainly not going to be able to test, verify and redundant everything: you will plan what is necessary to be able to do it by hand if the IT is in trouble.

Old-fashioned way

To fully understand the extent to which the previous solution is unsuitable for the context, let’s compare with the more traditional method that I have used so far…

Before the competition, the teachers send me an email with the list of judokas. They can send it to my teacher who forwards it to me. I centralize all this data in a single table. One or two days before the competition, I prepare the pools as follows:

• I sort the data by age category (replaced by a subcategory for the youngest), then by gender, then by weight,
• I make pools by grouping 4 consecutive judokas without mixing the categories then I will refine in several passes:
  • If necessary, I allow pools of 5 or 3, if possible isolated between pools of 4,
  • I move the judokas to distribute the clubs while keeping similar weights,
  • When a pool has a big difference in weight, I split it and distribute it to neighbors pools,
  • When there are too many or too few judokas in a pool, I share them with the neighbors pools,
  • After several passes, if there are still problems, I then look at possible upgrades and downgrades.

Once you get the hang of it, it doesn’t take too much time and the result is quite good. It’s like solving a puzzle so it’s even enjoyable when you like that kind of thing. The advantage is that if we think of a new constraint, we can apply it directly without wondering how to modify the program without breaking everything that was already working.

For the day of the competition, I print the list of participants sorted in alphabetical order with their pool number for each (in several copies). I also print the numbered pools’ sheets (but in sheets designed for 6 fighters, you will understand why later). I also print out some blank pool’s sheets.

On the day of the competition, we have two groups for check-in. Those who welcome the children note their identity, search the list. If they find it, they pass the line in fluorescent (this makes the search easier afterwards since we see the lines that we no longer need to read) and tell the second group the number of the pool and the children’s identity. The second group divided the pools into intervals, when they heard a number in their interval they found the judoka there and fluorescent its line. Once a pool is complete, it can be stacked separately. If a judoka is not registered, he goes to a nearby table to weigh him and register him on a new list.

This method is not slower than “CTRL+F”. It would even be faster because we are quicker to pass a line in fluorescent than to manipulate the keyboard to launch the search then write a name (all several times because with the noise we did not really understand how the name should be written) then validate the registration.

Once all the judokas have passed, while they are warming up, we have plenty of time to finish the groups. We cross out the names of those who are absent on the pools’ sheets (those who were not fluorescented). New registrants can be inserted into a pool of a compatible weight (they are sorted by weight) by writing their name by hand in one of the empty boxes. Because of absents, we can have pools of 1 or 2 which we distribute by registering them on neighboring pools. And if necessary, I have blank sheets to create pools or rewrite those that have become illegible.

Compared to a computerized version, we can clearly see that we are just as fast but we require less hardware, we have less risk of bugs, no risk of breakdown and it allows us to improvise in the moment (which computer does not allow).

And after ?

This example concerns the organization of a judo competition for children but it was a pretext because the principle is much more general. Whether in legal expertise or in normal life, I all too often encounter applications that have been developed with (very) large budgets and result in a white elephant that fail to resolve the problem that gave rise to them.

Each time, the customer dreamed that IT would make his life easier and found a provider to support him in his delirium. It would have been much more economical, ecological and even ergonomic to implement a “low tech” solution but this is not in the interest of the provider in the short term. Firstly because it yields more money; we can charge for more project management, more R&D and more maintenance. Then we remain on an obligation of means; since it is the customer who decides, it is he who takes responsibility and that is always a good news. And above all, the customer does not like to be contradicted; he already knows what he wants and will find another provider if necessary.

But it would be dishonest to blame customer ignorance and corporate greed because the root is also cultural among IT professionals. Teaching sectors spend their time asking students to model situations “taken from real life” in order to computerize everything. After several years of study, it has become a reflex: any everyday situation becomes an opportunity to demonstrate one’s virtuosity in modeling, algorithms and programming. We were given a hammer, we see nails everywhere. The problem is that where the educational situations had been chosen and calibrated to be computerizable, the truly real situations are much more complex, which introduces a hidden cost that must be paid one day. It’s a shame because most of the time, it only needs one step aside to find a simpler solution.

I dream of a teaching module entitled “the art of avoiding computers” (which we could also call “Keep It Stupid Simple”) where students would be confronted with classic computer modeling problems but would be encouraged to produce the simplest solutions. When we tell them that school teachers need to communicate with parents, they will lose points if they propose a virtual workplace and will pass the test by proposing a simple mailing list (bonus for those who remember that a contact book already exists and, unlike computers, teach children to be more responsible).