Extreme Programmers Paris #XProPa – Second meetup

Yesterday I went to the second Extreme Programmers Paris Meetup (#XProPa)

It started with an application code appreciation exercise. The idea behind this is was to go through some code and see how the developer who wrote it tried to be as clean as possible.

The code we went through has been presented by its author himself! Clément Boudereau brought his nice HardMock legacy code mocking framework’s code and explained us why he wrote it that way.

hrdmock

We needed first some explanations on what HardMock is all about before going deep into the code itself! Hardmock is a mocking framework that can produce integration test based mocks. It will work as a behavior recorder that will store the generated mock on a file on your hard drive. All you need to do is to write a complete integration test that might have to connect to a DB through DAL calls, or call any external services, and then extract all the interfaces for any dependencies needed and record the corresponding behaviors. HardMock seems to be a nice way to be able to refactor big balls of mud without having the need to spend as much time on refactoring hard to maintain unit tests as refactoring the legacy code itself!

Now that we knew a bit more about HardMock’s domain and its vocabulary it was time to see the code! Clément strived to make it as clean as possible: he made use of pretty well named variables and methods; he tried to be as SOLID as possible but at the same time he managed find the right balance between the need of abstraction and readability (like providing more than one constructor to users so they can directly call the one with the most common implementation)

1410286349084

At the end we saw a lot of well written code but the conclusion was that code was not like literature! Even if you know the domain, you can strive to be as clean as possible; it will be always hard to understand the whole story just by reading the code. And as Clément said, your code will never get clean enough; it’s an everlasting improving story!

The second part of the meetup was made of open space discussions about different topics people would like to speak about. I joined the Mob Programming discussion group where Thomas Pierrain told us the way they run their #SORLunchBox project and I also spoke about our own Mob Programming experience at my company.

As often during meetups, it was an open-minding night sharing thoughts with very talented and interesting people! Don’t wait no more and find out what meetups are next to you! See you there?

#CraftConf – Abridged feedbacks

You might ask, why did I stop writing feedbacks on Craft Conference sessions?

It’s just because I post them on my company’s blog! :-)

Here there are: Abridged feedbacks.

By the way, as a foreign Craft Conference ticket winner, the guys at Prezi (one of the organizer company) asked me if I was ok to do an interview with them. The fact is that it changed a bit and it moved to I had to film myself during the conference.

It was real fun and here’s the result:


Broadcast live streaming video on Ustream

#CraftConf – Jonas Bonér – Go Reactive!

Jonas is CTO of TypeSafe a company that provides a Reactive Platform which helps to deliver responsive, resilient and event-driven applications. Typesafe spearheaded the Reactive Manifesto which defines a common vocabulary for reactive applications.

Unsurprisingly, Jonas presentation was about why and how to build a reactive application!

We’re entering a new era. When building an application we now often have to deal with mobile devices, cloud computing, distributed components. We need to build softwares that are real-time, responsive…

IMG_20140424_121241

As Jonas said, our applications now have to react to:

  • events -> being event-driven
  • load -> being scalable
  • failure -> being resilient
  • users -> being responsive

In one word, they need to be reactive!

First of all, we need to go async! (see Amdahl’s law). We do need to avoid blocking processes (which kills scalability). An event-driven system makes use of asynchronous message passing which gives lower latency, better throughput and bring more loosely coupled components.

Our applications need to be scalable, meaning being able to be expanded on demand. Better scalability comes with systems that are built of isolated components that share nothing with loose coupling and that communicate asynchronously. We need to minimize contention and maximize locality of reference. One thing that need to be kept in mind while dealing with distributed computing is the 8 fallacies of Peter Deutsch: the network is inherently unreliable!

We also need to build resilient systems that are capable of recovering quickly in case of problems. We need to avoid defensive programming where errors are mixed with business logic and disseminated everywhere in the code. Our clients should only deal with validation errors, not with applications’ ones. Our services should be built both with a dedicated supervisor which role would be to handle things in case of issues. It should be up to the supervisor to decide what to do (kill, suspend, resume, …) and so business logic and error handling are decoupled!

Last but not least: responsiveness! We need to keep the latency consistent. We need to make asynchronous and non blocking requests and responses and switch from pull to push so that our UI’s are interactive and always synchronized!

Reactive

Links:

#CraftConf – Gojko Adzic – Flexible scope

First of all, I’m a big fan of Gojko’s work. I’m constantly trying to contaminate people around me and ask them to read Impact Mapping which I think might be a super duper solution to lesser the gap between IT and business people (and this is just one advantage amongst others! Just read it :-) ).

This presentation was not (only) about Impact Mapping, though, but more on how to write better User Stories. Gojko showed us how by spending 10 minutes more on writing user stories, they could be 10.000 times better  :-)

gojko2

The fact: our systems lack on flexibility. And that’s pretty strange, because this is always something people are searching for. Most of the time they’re even OK to pay more for flexibility (think about train of flight tickets that are much more expensive with some flexible options).

Systems are often built with a lack of flexibility and when their limits are reached people get into a crisis situation where the only possible option to keep the business alive is to Think & Redesign the whole system (and Measure if they’ve built it the right way this time!). But why wait for a crisis or chaos to do things the right way? Wouldn’t it be simpler to do it from the beginning? Make sense, uh? Jez Humble wrote about “Does Systemic Change Require a Crisis?” in his Lean Enterprise book. He quoted “The Corporate Culture Survival Guide” book by Edgar Schein. Pretty interesting.

Ok, so we should think about flexibility sooner. But keep in mind that trying to have a flexible scope is impossible without having a big picture of the goal to reach. User Stories are often disconnected from real business needs. Why? Because business people like to write what they would like to have on Power Point slides, not by saying things like “as a user I want this or that”.

gojko1

Tim Hartford wrote the Adapt book, where he tells us about the Palchinsky principles. As stated here: “Peter Palchinsky was born in 1875. He was a mining engineer who wished to take a more humanitarian approach to engineering […] He argued that Russian engineers did not approach problems in an “academic-dilettantish” way. Instead, they took on every problem as a purely technical one and assumed that if a solution incorporated the latest science, then it was the best solution”. Does this remember you something? Doesn’t it sound pretty familiar with what we’re experiencing today? Palchinsky said that linear plans never works because they do not consider Local, Time and Human dimensions. What would that mean? Well, did I tell you to read Impact Mapping yet? ;-)

So, how to take those dimensions into account? Think about:

  • Variation: search for ideas and try new things…
  • Survivability: …on a survivable scale, meaning where failure is survivable for your company….
  • Selection: … and get rid of those which do not work! (A/B test, monitoring, …), learn from your mistakes!

We somehow have to create a GPS for our apps! And as a GPS system would do, replan in case of problems! User Stories should somehow include the “excepted time for arrival” information!

How could we apply the 3 dimensions above in our User Stories? Here’s Gojko’s advice:

  • Variation: Plan to learn! US should not be commitments but options! We definitely need to change our mental perception of US.  Use what Tim Brown says in “Change by Design”: create options during what he calls a divergent phase and then make choices during the convergent phase.

divergentconvergent

© Tim Brown

  • Selection: Plan to discard mistakes: put a victory condition on your User Stories.
  • Survivability: Plan not to kill your company :-) Great User Stories are survivable experiments!

More links:

#CraftConf – BoÐil Stokke – Programming, Only Better – Keynote

Bodil is a well-known conference speaker that works as a developer at Future Ad Labs, a London based company.

If you’re used to read her tweets, you should know that she has a pretty good sense of humor.  That one she tweeted about 2h before her keynote was quite funny:

bodil

…and gave the right tone before she talks :-)

What I have to say is that I was not disappointed. Some of her slides (My Littlle Pony, cats’ videos …) and the way she ran her presentation, were hilarious. She also piqued my curiosity: now I want to know more about Dijkstra!

Well, being funny is one thing, but more important, Bodil made also a pretty smart presentation.

bodil1

After spending some time describing computer history she ended up with this question:  Would processes or good project management bring great code? Is being Agile the answer? Well even with the picture of Bob Martin Showing The Way with Extreme Programming like Moses raising the 10 commandments, the answer is no! Simply because people are different! Some people love doing pair programming while shier ones would prefer being concentrated on TDD. Do code review everything would be a silver bullet? Sure no….

But wait, why is there so much bad code? Is that a matter of what language you’re using? No way! The reason is simple: complexity! There is too much complexity in our software. Would testing save us, then? Would it be the way to deal with complexity? Obviously not, it’s almost impossible to tests every case. You’ll always find a use case that is not covered by tests and thus subject to bugs. Bodil quoted Dijkstra, what he said about testing was one of my favorite: “Testing is hopelessly inadequate… it can be used very efficiently to show the presence of bugs but never to show their absence”

bodil2

The cause is that we’re trying to manage a code with way too much possible sates, our code deals with way too much mutable objects that can have their state changed by any kind of unexpected side effects behaviors.

So, what would help up? Are we doomed forever? Sure not ;-). First of all, have a look at “Out of the tar pit” paper by Ben Moseley & Peter Marks where they explain why complexity causes so much trouble in our software and what would be the right way to deal with it.

Well, it might be time to look at functional programming language or at least adapt a functional way of programming in our code! How? There are some good recipes, think about that one: if you think your object or any class member should be immutable, just put a sealed (or final) keyword in front of it! It will also help in a multithreaded environment where no lock will be needed anymore as share object can never change!

Nouhoum Traore said this one time: “functional programming style is a programming style that has style” :-) We can do nothing but agree!

Links:

#CraftConf – I was one of the lucky ones!

It’s almost an impossible task to relate every single thing I’d like to, when trying to recap such an incredible conference.

The quality of the speakers and the talks were so great that the best solution would be for me to ask you to watch all the webcasts ;-) Ok; I know you might not do it, so I’ll try to summarize the best as I can.

First of all, I’d like to say that the place itself and the overall organization were perfect. Simply have a look at the tags every attendee received and you’ll understand!

tags

We had all the useful information in our hands: Wifi code, official twitter #hashtag, the schedule, conference map, city map, a little Hungarian language guide and even 4 free beers tickets for the party!

Oh, one last thing before telling you about the sessions: I was lucky enough to have a free entrance! Craft Conference organized a quiz on twitter, I participated and guess what? Yep, I won one of the 3 tickets!