Static or dynamic types?

Last friday, Gilles and I have organized the second edition of the "Mate, you have to see this!" event.

Gilles Philippart is the head of the tech-coach unit within our company (30 passionates developer-coaches that are transversally sharing their skills & experience all over the organization). He is also a big, BIG, fan of the Clojure language (and co-organizer of the Paris Clojure User Group).

"Mate, you have to see this!" is a kind of event that I was recently launching within our organization. The concept (already described here) is pretty simple:

1. We book a meeting room at noon
2. We project and eat our sandwiches in front of an inspiring talk in video that one of us has really liked
3. And we all debate afterward (it's a 2 hours event)

For the first edition last month, I had chosen an excellent french talk from Gregory WEINBACH (related to DDD).

This time, I've setup a doodle poll and we had reached the quorum for Rich Hickey's "Simple made easy" talk. At the end of the day, some of us recommended to replace it with a more seminal talk from Rich Hickey: Are we there yet?. I was not convinced by this choice actually (I find "Simple made easy" more inspiring & accessible), but we ended with it for our session.

Clojure

Did I told you that Gilles was very pushy around Clojure adoption? ;-) Yeah? no?

Because this time, he had contacted two major french ambassadors of Clojure to join us for watching the video and debating afterward. Those french ambassadors are:

• Christophe GRAND (co-writer of O'Reilly's well-rated Clojure Programming)
• Hiram MADELAINE (creator of the Paris Clojure User Group)

And to be honest, even if I really enjoy Rich Hickey's talks in general, the Q&A session at the end was far more interesting for me.

Let me sum up some of them for you:

The language

"Why did you choose Clojure and not another more-or-less functional language (like: Haskell, F#, ERLANG, Scala)?". 

Christophe GRAND -that started to use Clojure just few months after its creation- explained that he wanted to try something else at the time (than Java) and that the vision & the mindset of its creator was decisive. Rich Hickey is a pragmatist, and his programming language is part of a new breed of functional programming (FP) languages that are very pragmatic too (like F#). With their interoperability capabilities, we can use them in our day to day job (vs. Haskell).

Hiram explained that he wanted to exit his confort-zone and to find an alternative to Java few years from now. He was so amazed by Clojure (& its expressiveness) that he's now trying to favor as much as he can Clojure for the applications he's working on.

Clojure's toolset

"Compared to a mainstream languages like java or C#, how is the Clojure development environment today (IDE, test tools, etc)?" 

Well... it seems that all the reasons that made LISP a painful experience for some of us (remember your 'vi' sessions without any help nor syntax highlighting?) are obsolete with Clojure & its relatively mature ecosystem.

Code-Designing Process

"FP removing the side-effects that we found within OO code, do you still need to write tests? If yes, when do you write them? And is TDD a valid approach with Clojure/FP?"

Ok, neither Christophe nor Hiram are following TDD to drive their design process, but both of them confirmed that they write tests for their Clojure applications. In fact, REPL -Read-eval-print loop- is the alternative here (i.e. the ability to interactively execute part -or- all the lines of code from within a console). The usage of the REPL facilitates exploratory programming and debugging, for something that Uncle Bob is calling "Eye Driven Development" (EDD). The developer in that case is "playing" with his code within the REPL until he's reaching what he wants. Once he has found a satisfying result, he can then put his code under a test harness (for non-regression, but also for a means of documentation). But even if both Christophe and Hiram don't do TDD in Clojure, it seems that other guys do (like here, or like Jérémie GRODZISKI -according to my mate Radwane HASSEN).

For me who am not strongly confortable with a FP language yet (lazy bast... I am), this is a very intriguing question. I mean, I can easily grasp the utility of the REPL for building and troubleshooting small functions. When I TDD with tools such as NCrunch and NFluent (in .NET), I somehow transform my augmented IDE into a kind of REPL (to have this immediate feedback on my baby steps). But I can barely grasp how to leverage on the transiant REPL for more than few small functions. For bigger code bases I mean. Will I pollute my developer's head with tons of contextual details (such as: did I include all the relevant code parts for this experimentation to be relevant)? But for now, I guess I need to learn and play more with FP languages than I already done (in a casual mode so far).

Performances

"Since Clojure is hosted within a JVM, are you sometimes jeopardized by stop-of-the-world-GCs?" 

As a disclaimer I would add here that every time Rich Hickey is talking about "good performances" within his talks, you can translate it into "good throughputs". It's a fact that Clojure code - with all those immutable data structures - is made for parallelization. On the other hand, an important memory allocation policy under GC may have severe impact on your application latency.

Well... even if Clojure immutability usually embraces short-lived memory allocation -which is very GC friendly- Christophe admitted that for some "niche" usages, he has been forced to tweak the JVM, to hunt down hotspots and even to rewrite or optimize part of his corresponding Clojure code in rare cases, to reduce allocation. Fortunately this is not needed for all Clojure applications, but only for the very stressful ones like we can found sometimes in financial front-office (i.e. a niche usage).

We also shortly talked about the concept of Software Transactional Memory (STM) that Rich Hickey addresses in his "Are we there yet?" (not the best part of his talk according to me, and a clumsy topic actually).

But our conclusion for this performance "chapter", was that we need to measure, to measure everything before going into production (confronting our systems to our use cases and contraints; not to our intuitions ;-). In clear, that means performance tests for everyone ;-P

Accessibility/Maintainability

"Do you have an example of a real Clojure application that is under production since various years and that has been maintained by someone else than you?" 

Was one of my questions. Haunted since many years now by this maintainability concern (i.e.: what makes a system surviving to changes? how to preserve original intentions despite turn-over?), I am curious about this challenge with FP languages. Will the utter concision of some FP language make this challenge even more complicated than with OO mainstream languages? As much as complicated? Christophe told us that he had an example of that for one program he started to build for the CERN various years from now and that has been upgraded and released by other guys once Christophe had left the site.

Static or dynamic types?

As I was explaining to the guys that I was currently hesitating between starting to learn F# or Clojure, the major difference between those 2 pragmatic FP languages aroused the discussion.
Before we had this discussion, my gut feeling favored the static type option (thus like F#), but
according to Christophe, it seems that there is a interest for not relying too soon on strong types when you are designing your application. Indeed when you start a program, there are lots of undefined things, including the kind of data you will work on (usually coming from outside/integration constraints). Creating types to early may be painful, but also hurts the reuse of your applicable functions and limits your expressiveness.

Radwane, currently looking at F# seriously was saying that he really enjoyed its static type system. According to him, it's so easy and fast to declare a type in F# (one or 2 lines) that it wasn't really a problem to create them. As a side-effect ;-) : "when your program builds, it means it works".

Well... I guess I'll have to play a while with those 2 languages before I can make my choice.

Anyway. I'd like to thanks here again Christophe and Hiram for having join us and made this "Mate, you have to see this!" episode so interesting.

Raising the bar

It's been a while now that we organize and attend various kind of Software Craftsmanship events at work.

Usually at noon, we leverage on our big company infrastructure (meeting rooms, town halls,...) to gather more and more people -month after month.

Our objectives: to meet, share, connect, learn, debate, code, hack...

After few years of difficulties (we faced some issues while our organization was scaling), we started now to raise the bar collectively by improving here and there our overall mindset and curiosity.

There is still lots of things to improve -mos def- but I have the feeling that we have triggered some kind of snowball effect here. A positive snowball effect.

Let me describe you the kind of events that continue to help us on that journey.

Brown Bag Lunches

The concept of Brown Bag Lunch (a.k.a. BBL) was probably the spark that ignited the fire of that positive dynamic. And this is still a very popular kind of event here. Probably the most popular one.

Introduced within our company by Romain LINSOLAS -our local Huggy Bear- and from an original idea of David GAGEOT (famous french Software Craftsman), the concept is pretty simple : we contact a speaker -usually an external one- and we welcome him for a free talk within our wall during lunch time. It's free, opened to every developer (first-come, first-served policy for seats). The topic may be whether on a craftsmanship technique, an open source library, a noSQL db, a kind of architecture (e.g. reactive, distributed, lambda, hexagonal), a low-latency middleware, etc.

Everyone is coming with his own Brown Bag (for the sandwich), and the organizer generally pays the speaker's lunch.

Usually between 1 or 2 hours depending on the topic and the Q&A session, this is the perfect spot for anyone to learn stuffs (even for the "I  have no-time for market watch" guys).

For the speaker it's a good way to prepare himself and to rehearse before a more official conference (like we did for our DEVOXX sessions). It's also the opportunity for him or her to meet and chat with other craftsmen, or to be the first one that the company will call when expertise on that area or product will be needed.


Since we have a lot of speakers working within our walls, but also a crowded audience of developers, we recently started to organize internal BBL sessions (with internal speakers). Some of us are also now "baggers", being capable to meet you within your company to talk (done with my mate Cyrille DUPUYDAUBY at betclic for instance).

If you are in France and want to organize BBLs, don't hesitate to consult the official site: http://www.brownbaglunch.fr/ to find speakers near your office. You won't regret the experience!

Coding Dojos

Widely-known, the coding dojo is an excellent way to learn and discover other concepts or techniques. It's also a great occasion to connect with and to have lots of fun with other passionate developers.

The concept? We meet at noon (10-20 persons in the same meeting room) and we try to solve in one hour or two, a small problem (the code kata) proposed by the chair of the session. 15 minutes before the end of the session, we all stop our progress, and make a public retrospective to share and challenge our various approaches. The occasion also for the chair to give us more hints about this kata that he usually has made before (few times, in other contexts).

Regarding the logistic, almost everyone brings his personal laptop. But since we usually pair, even those that didn't have a laptop may code. Depending on the kata also, everyone is picking the language of his choice to work it out (Java, C#, Javascript, F#, Scala, Clojure, Haskell, ...). 

Firstly introduced by my friend and eXtreme Programmer Philippe BOURGAU, Cyrille MARTRAIRE and Gilles PHILIPPART were truly the ones that institutionalized the coding dojos then, as a regular event. Indeed, even if this summer was pretty quiet, last spring there were almost one coding dojo per week (usually nicely chaired by Eric LE MERDY). But I must admit that I miss the fun, creative and very informative sessions chaired by Jean-Laurent DE MORLHON (working elsewhere now). A true mindset inspiration for me, when I organized some of them afterwards.

By the way, here is a hint for you if you want to launch this kind of events within your working environment: don't hesitate to find an incentive to break the ice and make new developers joining the movement.

The chicken and the egg situation

Indeed, someone that never attended a coding dojo will be often reluctant to join one, but those that have tasted a coding dojo once, will usually be recurrent attendees.

That's a fact, a coding dojo may firstly appear impressive if you never attend it before. Will I be able to pair with guys I don't know yet? Will I be able to code as fast as the other attendees? ... are common questions silently un-asked. But once you've attended a first session, the result is always the same: we all realized that it is not only easy, but truly fun! (and BTW, kata aren't about complex algorithms, nor about any given tech stack that you wouldn't know)

To reach some .NET developers that were not used to contribute to such events (and probably a little bit shy or anxious, since they had lots of excuses to refuse again and again), my solution had been to make a deal with our purchase department and Microsoft, and to offer temporary MSDN account activations (i.e.  the ability to download a tons of MS product for free) to every developer that will attend their first coding dojo.

Whether you are contractor or internal employee, you will be able to install Visual Studio on your personal laptop, but only if you attend a coding dojo first. Here, I have to thanks again our purchase division mates, and our contact in MS for that. Because with that thing... No more chicken and egg problem for dojo attendance.

I won't detail much more on coding dojos, there already are lot of literature on that area, but simply give you some of my favorites: Gilded Rose (legacy code refactoring), The ("office") code carpaccio (my personal adaptation of the code carpaccio kata. i.e. how to slice your work in order to add business value on every 8 minutes iterations), Mars Rover (perfect for TDD design), the Cash Register (how to avoid being blocked by fragile tests when business requirements are changing blazing fast), etc.

Hackathons

Organized by our company, and hosted by Ecole42,  this hackfest has mobilized lots of developers during an entire WE (too bad that wasn’t during the week), around the theme: "create new kind of collaboration tools for distributed dev teams". A nice initiative that will surely be reproduced in the future.

Some other ideas we started to launch recently

"Hack da cafeteria"

During a recent discussion with Bernard NOTARIANNI (co-founder of the Paris #XProPa), we had an idea for a new kind of lunch-event.

Indeed, while I was explaining my proposal of organizing dinners in Paris for XP practitioners: wine, food and craftsmen (explanations here in French), he stopped me and said: "nice idea! but why don't we start here, within this company, by hacking the cafeteria at noon for debating around development topics?", "That's right! Why don't we?" ...  The concept of the Hack da cafeteria event was born.

This concept is pretty simple: we join the cafeteria with a topic to debate and to share about with other real practitioners (e.g. "How to convince skeptical dev and project managers to allow pair programming?", "Mob programming, how does it work for you?", "CQRS & event sourcing in action with concrete cases", "How DDD practices helped us within our projects", etc).

We split ourselves into tables of 6 to lunch and debate the topic of the day. After a 1 hour of lunch-debate, every tables merge for the coffee in order to share with the others tables their 2 or 3 highlights.

At the end of the day, a short minutes may be forwarded to anyone interested by this topic (especially the people that are not practitioner already, or located at the other side of the globe ;-)

The very first session is already scheduled and will occur early September. I'll surely post something about it after.

All those events are easily affordable, and are perfect occasions to break silos and to connect people from different cultures, teams and habits.

"Mate, you have to see this!"

Is another stuff to do at lunch-time. Something I would have liked to organize since a long time, but that I will actually schedule in 2 or 3 weeks from now (I've made my poll, and it seems that there is appetite on this too ;-)

The idea: to display somewhere at noon, the video of a talk, conference, quickie, ... that strongly impacted one of us, and that we wanted to share with peers. Not only to share its content by the way, but also to debate all together on it afterwards.

You don't have time to do some market watch? Let yourself leverage on other mates' best discoveries! Simple, easy, and the opportunity to open some technical debates, even if you can't attend some meetup evening events in Paris (what I call my geek evenings).

I've read pretty much the same concept within Sandro's book with tons of tips for the logistic when we don't have access to the ideal rooms/theaters (even if I'll try to borrow our official theater at work, if this initiative is having success). And we already have lots of videos (and debates) in mind for the first representations...

And last but not least, I'm proud to introduce you

The Lunch-box mob

How would we properly implement event sourcing to add more business value and audit trail capabilities to an Order Management System (OMS)? Will we be able to leverage on the LMAX Disruptor without being forced to reimplement all the associated LMAX stacks in .NET? (i.e. ressources pooling, cache-friendly collections, etc) How would we implement a Smart Order Routing system (SOR) with relevant low latency and throughput performances, but without scarifying code readability & maintainability for non-experts? Which programming paradigm to choose for this kind of reactive system: LMAX disruptor-based? In-house Sequencer-based? RX? F#? 

... were some of the questions that led Tomasz JASKULA (DDD and F# Paris co-founder) and I to pair together at noon with our laptops in order to spike and build stuffs (yeah: enough said! time to code ;-)

That why we created the Lunch-Box github organization, and started to work on an open source Simple Order Routing (a kind of Smart Order Routing financial system, but without the smart algorithm part). The #SORLunchBox project was born! (see details on the project's wiki)

We've been since joined by some mates that have both the SOR functional knowledge and the envy to collaborate. Again:  our Mob programming crew was born! (with 4 people for 1 keyboard and a big screen).

This is the very beginning, but since we are not working on the same teams, we decided to meet at least 2x2hours a week -at noon- to work on it. We split our project into various journeys, and will probably keep a logbooks to diffuse what we will discover, next to our code which is open sourced.

This kind of experimentation has lots of benefits. It has already learned us various things (functional, mob programming organization, etc.) and bring lots of fun too! And who knows : maybe this spike open source project will help other teams, but also help ourselves (through the feedback of people elsewhere).

Experiment, talk, learn, debate, build, and share

What i'm saying, as a conclusion, is that you always have lots of benefits to experiment, talk, learn, debate, build, and share. Yes, sharing your passion, your failures, your discoveries is good, and helpful. For you, and the others.

Most of the events and occasions I talked about in that post are free and very easy to organize. Don't wait that your company or structure help you to start. Also, don't expect to have lots of people with you to start doing things. Start with 2 people, communicate on it, have fun... and let the other join the initiative.

Be the spark that will ignite the fire of Software Craftsmanship within your organization!