30 Mar 2016

Coding challenge: improve your delivery process!

At job, we like to develop our Software Craftsmanship culture by organizing Dojos, Katas but also, time to time, coding challenges.

So, last month, for two hours, about thirty developers were pair-programming to solve the Extreme Carpaccio problem.

I decided to ask Gilles, one of our Delivery Managers, his feedback about this event. As he is an “aficionado” of Software Craftsmanship, I think it’s interesting to share that feedback with you.

2016-01-27 14.23.10


Xavier Balloy: Hey, Gilles, so you decided to code with us for this challenge we organized last month at our Web Center! What did you think about it?


Gilles Cruchon: Well, first, it was really exciting to see that the room was full of developers. It means that lots of our team members really enjoy programming and are ready to face new challenges! Also, personally, I would mainly remember several things that I’m fostering  since then:

  • We should deliver value as fast as we can (even small value) …
  • … but we ought to take our time in the early phase of development so as to produce only robust and resilient code.
  • We should do everything we can to maximize the uptime of our server (ship without any downtime, if possible).
  • Knowing our IDE is a key to success.
  • Though it may be very surprising on a first approach: TDD is the most efficient to deliver quickly because:
    • our code is bug-free;
    • our code is robust;
    • our code is resilient to unexpected changes (we can quickly and cleanly adapt our code to fast changing environment).
  • And last but not least: no matter how good we can be, there is always room for improvements! For example: we can maximize the value we deliver first by analyzing our specifications and prioritizing we backlog.

And you, Xavier, as an organizer, what are your thoughts about this coding challenge?


X. B.: Well, at first I was impressed to see that some team managers joined us for this challenge. That means that Software Craftsmanship culture doesn’t belong to developers only! Then I enjoyed that people used different languages to do this challenge, it kind of added another kind of competition between teams. A couple of teams used Java, a few Node.js and the others C#. The teams using Java didn’t used the starter kit and used their own stack.

The last thing is that some teams used the TDD approach even if the challenge was timeboxed and that the faster you deploy the earlier you earn money.This is very revealing of the mindset of the developers: TDD does not take more time!

Oh, one last question… What would you propose to improve this challenge?


G. C.: Good question everyone should always wonder! Well, first, though there was a starter kit (server and log console), I noticed it was long for several teams to go “online” very fast. Therefore, we could get a better help there, setting up environment not being part of the challenge. I would have also liked some buggy JSON messages sent to our servers, so as to emphasize the importance of robustness of the code. Finally, if more changes would have occurred in the data-flow to servers, we would have been able to notice even more how fast it is to change a piece of code when it’s covered by tests.

And you, is there anything you would like to improve in this challenge?


X. B.: I think that your ideas to make the challenge more challenging are interesting. One way to improve the challenge would be to make team lose money when they are offline. It would force teams to always have a server up and running, because in real life we try to minimise downtime. Another thing would be to have a way to earn money faster because it’s currently almost impossible to overtake the winner if he’s already handling all the cases. Maybe using performances and response times?

All in all, many teams enjoyed the challenge and I’m really looking forward to our next challenge, a fun way to improve the way we craft software here in Lille.

  • Diego Lemos

    Well done guys 🙂