Summary

Things I learned, heard, discovered, was amazed of, during :

• Thanks to Willem Van den Ende, I learnt of the existence of, a project to buildembedded and isolated servers hosted by a single Linux kernel. Iknew and have used butlxc appears to have much wider support and a quite largecommunity.

• I worked with Willem (again!) on a very nice idea of its own:Managing tasks of projects using graphs whose nodes are tasks and edges are dependencies. Thegraphviz file is stored alongside the project in a git repositoryhence versioned and updated over time while the project isunfolding. Tasks may be added, deleted, changed and grouped underclusters (eg. subgraphs) representing common state: done,inprogress, todo, technical debt...

• Together with Willem we hacked a Haskell solution to extract datafrom such a graph in order to produce a Cumulative Flow Diagramfor clusters, thus giving some statistical information on theprojects' progress, lead time and queues size.

• Although the Graphviz package's API in Haskell is a bit weird atfirst, we managed to get somewhere in a relatively small time framewithout prior knowledge of this API, which is a tribute to itsdocumentation, above the average.

• While working with Willem, it occured to me that creatingtasks/issues/tickets classified as technical debt was actually apretty good idea. This is not the first time I came across it but Inow think I will set it up on my next project, and extract regularlyfor the team some metrics on the amount of accumulated technicaldebt.

• The fact that, by reifying the technical debt items in the projecttracking system, one gets the opportunity to prioritize it like anyother feature, is definitely a plus. Now, technical debt issomething that flies in the face of all stakeholders and teammembers when deciding what to do next and we can ground ourdecisions on whether or not we are ready now to accumulate or repaypart of it.

• I took part in a session on Agile Teaching with an aim towardsmaking courses and teaching to students more amenable to agilemethods. Laurent Bossavit told us about its experience at Ecole desMines de Douai with a 3-days intensive course which gives studentthe opportunity to practice every aspect of the developmentlifecycle using agile practices and techniques, something which ismore difficult in a sliced lesson taking place over the course of asemester.

• Laurent also wisely remarked that we tend to transpose ourexperience as trainers for professional developers in a corporatesettings to students, which is most of the time wrong.

• Everyone agreed on the importance and benefits of workshops andagile games which, apart from boosting the morale of students whoare bored to death by slideware, provides a rich interactiveexperience to build a more theoretical analysis. I myself tend tostart with theory than illustrate with practice which is not sogood and this is something I shall change in my next courses.

• Etienne Charignon demonstrated how they have used FitNesse as theironly testing tool on a recent project and how successful he thinksthis experience was. Their approach was radical: They did not writea single unit test and used only FitNesse to drive their*development, something which sounds impossible to me. Yet theysucceeded in delivering a high-quality application (except maybe inthe GUI area which, as far as I can tell from what Etienne toldus, lacked tests) which pleased the customer.

• They were lucky enough to have onboard an analyst with some devbackground who wrote most of the initial tests and maintained theFitNesse. They also had few business logic, the application beingmostly a front-end to some database, hence testing with FitNessetables was really expressive.

• I was impressed by how they used FitNesse as an integratedspecification tool, putting all relevant documentation alongsidethe tests and structuring them using features and functionalareas. I always had mixed feelings with FitNesse as most of the timeI tried to introduce it, I had a hard time onboardingnon-developers, although I am really convinced of the interest ofsuch a tool to provide accurate, structured and precisespecification of a piece of software.

• In the train bringing me back home I chatted with Pascal and Luc andour discussion happened to fall on the tests as specificationissue. We both agreed that, if only developers are involved inwriting tests, it is better to devise the tools and processes togenerate specifications from the (JUnit) tests than forcingdevelopers to use a tool that gets them outside of their efficiencyzone (eg. outside of the IDE/CI cycle).

• I ran the gamewith Willem (I spent a lot of time with Willem in this conference!)on Friday morning. We gave it a little twist by requiring teams toselect a constraint. This time we played the game, in Haskell, withthe constraint of not using the REPL which was really alleviatedwhen we managed to make Haskell's doctest port running.

• Other teams had constraints like: discovering git while developing,not using unit tests, developing on the iPad (kudos to LaurentBossavit who managed to have a web server in python running on itsiPad!).

• This was fun and engaging, as always, and Rapha��l gave me an idea tomake it more fun: Allow people to participate in the game asinvestors, fuelling the participants with time to develop theirsolution according to their business plan and their existingcodebase.

• I proposed a session inspired by Dan North's talk and some blog posts from himand Liz Keogh on this subject: How some teams get past standardagile practices to deliver software more effectively. The wifi waslame in the hotel so we could not watch the talk or even a fractionof it, hence the discussion was a bit biased by my vision of DanNorth's vision.

• In the bus back to Strasbourg's station we had an informaldiscussion on Designing for Operability. Pierrick talked about hisexperience developing a software which is both used in SAAS andhosted mode. The most salient aspect of their approache is that theydeploy a software without proper sysadmins (eg. developers are thesysadmins), and the software is autoinstallable and autoupdatable,thus alleviating the need for complex installation and upgradeceremonies.

• Julien who works as head of an operations department gave us somemore insights on how a large organization handles this. One of theirstrongest requirement is that everything that gets logged by anapplication they operate should be tracable: A UID should identifythe error condition in all layers of the system (eg. client andserver) and no log should be produced without it. They also ensurethat code deployment is simply done with a checkout from SVN andthat tools between developers' stations and servers areconsistent. Binary artifacts are versioned.

What I Will Do

• More Haskell: This is a great language which is easy to develop within all current environments. I have been loving it for years andstill find it amazing... I plan to revive my git-p4 bridge, makingit more robusts and usable, and develop a programmable maven shellin order to simplify maven builds and common commands.

• Use FitNesse as documentation hub: Instead of splittingdocumentation across various repositories, wikis, documents, Iwill try to ensure all project's documentation is kept in FitNessehence versioned alongside the project.

• Improve FitNesse tests quality, and turn them into a realexecutable specification. Given that I shall start accompanying anew team soon, I will take the time and responsibility to maintainthe Fitnesse and write more tests, more easily, in order to providea good feedback on where the project is as early as possible.

• Run Extreme Startup: This game is both fun and instructive. Iwill submit a proposal to run it for next Agile France conferenceand at my current work. I will try to add more questions in order toprovide variety and possibly rewrite the graph display part whichsucks.

• Review Dan North's talk again.

• Track Technical Debt