Final thoughts on the ICPC 2011 industrial challenge

I have received the review of my submission to the ICPC 2011 industrial challenge. If you have read the challenge description, you may remember that participating involved writing various fictional e-mails. In my submission, I skimped a bit on that part. Some of the e-mails I replaced by an e-mail to my fictional boss, explaining to him that my holidays had started and that he was in the best position to write them anyway. Which he would be. In fact, being my boss, he would know me well and prefer me never ever to write directly to important customers' CEOs.

That these e-mails were required tells something about the ICPC conference (that I have never attended and that I would not have thought of attending without this contest). \Comprehension" is the key word — with respect to what we are already concerned with in this community anyway. It's not just about the programs it's also about the humans that have to deal with the programs. In some ways we completely ignore these aspects: we would like the person verifying the software to trust that it works in the same way that you may trust a counter-intuitive mathematical result with a proof each step of which you can check is correct. I am naturally exaggerating our differences here: before the formal proof someone has to have the intuition. We are not working in opposite directions we are simply working each on difficult subjects that until now have been occupying all our respective attentions.

Even more telling is that in places were I did not think I was skimping the organizers expected more human/economical/social/psychological thinking than I provided in good faith. Where the contest required an e-mail to:

RobotControllers.com Quality Assurance: Explain to this non-engineer how the code caused the cus- tomers’ problems and what effect your bug fixes had on the program’s output. Instruct this person how to recognize symptoms of the bug that may be communicated by customers.

I simply wrote (people who have interacted with me on Frama-C's own issue tracker will recognize my patented style):

Issue 1:

Description: When the moveby command is used the robot leg moves very slowly.

Workaround: Do not use the moveby command. Status: Fixed in last revision.

Issue 2:

Description: The robot leg does not stop jiggling when it hits the target angle. Workaround: No workaround known. Status: Fixed in last revision.

Issue 3:

Description: When issuing an order to move in a direction opposite to the one the leg is currently moving destruction of the robot. Workaround: Wait for the completion of any command before issuing any new command that would cause a change in direction. Status: Fixed in last revision.

Issue 4:

Description: At the end of medium-range move orders the leg stops moving abruptly. The robot smells slightly funny. Workaround: Issue only short-range orders where the leg does not build up speed or long-range orders where the leg reaches its full speed. Status: Fixed in last revision.

The reviewer had the valid remarks below (I hope ey won't mind that I quote em here. We're bridging the gap between two communities! If we have to breach etiquette and quote excerpts of reviews that are supposed to remain confidential so be it…)

the QA person needs advice on how to recognize when a new caller is reporting a similar bug; the explanations of the details were too vague to direct callers properly. QA also needs to know what to say to the customer when a bug is recognized: In addition to technical workarounds is it possible to return the chip? Is there an alternative available? Is there a testing method suggested for discovering similar flaws at the customer site in the future? Should the customer be compensated for exploded controllers?

I will be attending ICPC 2011. I hoped Anne Pacalet would be there too (as I already pointed out she implemented the code navigation features). She won't be able to come but she wants me to take notes during Margaret Burnett's invited talk.