Øredev 2013 – What you probably missed

Øredev 2013 was last week, and it was fantastic!

Sharing knowledge

Øredev is in Malmö, Sweden. It’s very close to Copenhagen, so you can fly to there and then take a 20mn train to arrive in Malmö.

It’s a fantastic conference, totally vendor-neutral (that’s very important). It’s big yet friendly, with a mix of well established topics and more experimental ideas. This year the theme was “The Arts”, and as a result it was deliberately provoking or weird in some aspects, and that is a good thing!

For me the highlights of the conference were the radical ideas brought by two guys with some experience in the business: Woody Zuill and Fred George (I’ll come to it in a minute). I also enjoyed a lot how Jessica Kerr @jessitron manages to make alternative ways of thinking more accessible and attractive for developer using mainstream languages like Java or C#. Unfortunately I missed @Bodil talks because the room was too packed to be even able to open the door…

Before the conference you can attend 1-day trainings, and I decided to attend the Value-Driven Product Developmentcourse by JB Rainsberger @jbrains. It’s a very good course, more advanced and probably not for beginners. I knew a lot about BDD and has attended other courses already, yet I still learnt a lot during this workshop. I missed other talks from JB, but I want to watch the videos since I had very good feedbacks from other attendees.

It was interesting to listen to experience reports (New Frontiers For In-House Legal Practice by Kate Sullivan, Data @ King – How we are able analyze 100M DAU by Mats-Olov Eriksson, Curiosity killed the cat, but what kills curiosity?by Ann-Marie Charrett @charrett, Less is more! – when it comes to art and software, by @JimmyNilsson) with anecdotes and honest accounts of successes, failures and evolutions of mindset.

Radical Ideas

The Øredev program committee likes to take risks and challenge the way we think about software, as demonstrated by Woody and Fred talks, but also through the talk Code as a crime scene by Adam Petersen Tornhill @AdamTornhill?. Adam tries to reuse forensic methods used for crime investigations to help on large legacy code bases. He built the tool CodeMaat to visualize likely aggressions on the code base based on these ideas.

More radically, Woody Zuill @WoodyZuill talked about the Mob Programming approach his team has been practicing for some time now. He does not claim you should do the same, and he explains that this approach is just the result of doing more of the good things as found during retrospectives. His team found that working together on one task at a time on one single machine at a time was good, so they decided to do that all the time. You must watch his talks: Mob Programming, A Whole Team Approach (Roy “Woody” Zuill). It includes a time-lapse video and is very interesting. It also challenges the way we think about work. What if what the actual “work” was actually what’s between what we usually call “work”?

Very radical too, Fred Georges @fgeorge52 talked about his approach of Programmer Anarchy, “because that’s what it is”. He’s now replicated the experiment at two different companies including a rather traditional one (the Daily Mail newspaper), and is starting again in yet another. Again he does not claim you should do the same, just that it works for them. Again using the power of retrospectives, they got rid of every role except just the customer and the programmer roles. They don’t use the usual software craftsmanship practices like testing and refactoring. However they take great care of the business domain, just like a trader and a developer working closely together can end up giving suggestions to each other, in both ways. As Fred says: “Power to the programmer!”.

This approach works thanks to the use of Micro-Services. This style of architecture in itself is also a bit radical, with a “rapid”, an ordered bus of all the events of the whole system, and a lot of very small, cohesive, disposable micro-services that listen and publish to the bus. You can copy-paste a service to create another, you can rewrite a service rather than make changes, you can plug your new service directly into production! It may sound chaotic but in my opinion this style is disciplined indeed.

Woody gave another talk No Estimates: Let’s explore the possibilities (Roy “Woody” Zuill). It’s really a beautiful talk thanks to the beautiful illustrations from his wife Andrea. Woody does a great job at making us question our need for estimates, what it really means and how it can harm. More importantly, he suggests that estimates are an obstacle against delivering something truly wonderful!

I was lucky to spend some time talking with Woody and Fred, and what they do is very exciting. It’s a paradox, but both still really follow agile values, despite taking huge liberties with respect to the usual principles and practices. Both Fred and Woody also know a lot about object oriented principles and made sure their teams was skilled in that too. However in each case the experiments are also biased because of the very presence of outstanding developers like Fred or Woody!

Testing is not just checking

Software development requires a mix of many different skills. Some of the important skills revolve around testing. At Øredev you could listen and talk to some of the most notable representatives of the testing community: Heuristics of Testability (James Bach) @jamesmarcusbach, Regression Obsession (Michael Bolton) @michaelbolton, Balancing ATDD, GUI Automation and Exploratory Testing (Michael Larsen) @mkltesthead?, (Curiosity killed the cat, but what kills curiosity? by Ann-Marie Charrett @charrett). Other talks (The Beauty of Minimizing Effort and Maximizing Creativity While Integrating Performance Throughout the Lifecycle by Scott Barber and The Psychology of Testing, by M isko Hevery) were also about testing.

I realized that testing is much much more than just checking facts. There is a whole universe of testing practices that you are probably not even aware of, and most of this universe cannot and should not be automated.

Software development is a creative job!

As part of the theme “The Arts” some talks were not about software development. I really loved the talk Shakespeare in Dev (Thomas Q Brady) and the opening keynote of the second day “The Creativity (R)Evolution” by Denise Jacobs @DeniseJacobs. Denise managed to trigger the desire to write, talk and share insights from many attendees in the room during her keynote!

My talk

I was excited to talk at Øredev on Friday after lunch: Refactor your specs! (Cyrille Martraire) The room was almost full, which may suggest that the topic is of interest for many. As a speaker I loved the professionalism of the staff doing the video, sound and organization all around so that everything runs smooth for everyone. Thanks a lot to you all! Overall my talk was well received and I had many good questions and very good feedback’s. As I said, this talk is just the beginning of a conversation that will go on, so feel free to contribute.

All the Øredev videos are available on this page: http://oredev.org/2013/videos (still not complete at the time of writing), so have fun and enjoy them all! Also have a look at the #oredev hashtag on Twitter for more quotes, and don’t forget to follow me at @cyriux on Twitter!






Read More

The Arolla “ancient world map” of software development

Software development technologies and trends are not particularly tangible things, yet we need to reason on them. At Arolla, the company I’m part of, we’ve designed an “ancient world map” of software development, as a cartography of the universe of software development we live in. Built for our own purpose, we also share it so you can benefit from it.

 The Arolla "ancient world map" of our software development universe
The Arolla "ancient world map" of our software development universe

If you want to use the map with your own teams, please do so (it’s licensed CC-NC-ND). If you need a high-resolution file for print, just ask (the file is quite big). We’d love to get your feedback!

The metaphor of an ancient world map

Agile and in XP suggest using metaphors to help materialize abstract stuff, and make it easier to grasp. You’ve probably seen Eric Evans (Domain-Driven Design) showing a picture of an ancient world map when presenting his concept of “a model built for a purpose”. We wanted to materialize software development technologies and trends, for which we have no clear and accurate visualisation yet, just like explorers in the middle age had no accurate knowledge of the world, lands and oceans. Ancient world maps had to represent that part of ignorance, with dragons and strange creatures on the less-known areas.

So we chose this metaphor to represent our universe. And ancient world maps are beautiful too!

A map conveys meaning

In cartography, the role of map design is to:

Orchestrate the elements of the map to best convey its message to its audience.

In our map, each continent represents a particular chapter of related technical stuff , and oceans in between represents “soft” techniques that complement them best. Of course the universe of software development has many more dimensions than the two dimensions available on a map. This means that such map is quite subjective, it depends on our own mental model. On the other hand, this is also true for any map of the physical world, that is also supposed to represents a 3D planet onto a plane, with some deep decision on whether to preserve angles or distances.

We tried to put most related technologies as close as possible to each other. Regions in the middle of the map represent the core of a developer daily work, in contrast with the regions closer to the poles which are more specialized.

Of course not every existing technology and trend was included on the map, especially the ones that we do not want to offer to our clients or that are of less importance. As a fan of DDD I regret we could not include our clients domains (finance, e-commerce, media, e-advertising, online games…) on the map, but a map is for a purpose, just like a model. A map of everything would just be useless.

Drawing the map proved a lot more work than expected, with hundreds of layers and lots of little adjustments everywhere, resulting into a huge file for printing.

To discuss skills and areas of expertise

Why this map int the first place? At Arolla we wanted to organise a session for all our consultants to discover more about each other from a skills point of view. We also wanted more senior consultants to volunteer and take ownership on some areas of their technical expertise.

We didn’t want another boring evening with slides shows in front of a passive audience. We wanted a more concrete, more fun and more engaging way to talk about technical skills and areas of knowledge.

So we printed the map on a big poster laid on a table, like in the captain room in an old vessel, and made it into a game.

Map + Lego = game

During last June DDD Immersion course at skillmaster, Alberto told me about Lego Serious Play. This game helps people express their ideas and be creative using Lego bricks as a medium, to help say crazy things in front of other people. It also makes any discussion a lot more fun! So we bought a set of Lego mini-figures, including some crazy figures, for our consultants to play with on the map (we did not follow the actual Lego Serious Play game at all).

The first part of the game was to get familiar with the map. I was shouting the name of various technologies at random, and the first to find out where it is on the map would take a marshmallow and place it as a flag (we had lots of sweeties everywhere too). This part was fast-paced and didn’t take long as it was quickly obvious that everyone had understood and indexed the map in their mind already.

Putting marshmallow on the map

In the next part, we had to create our own Lego persona, using the Lego building blocks available. It was really fun, and everyone was really happy to be given the opportunity to play with Lego again. It was nice to see that nobody built a mini-figure as planned on the box, they were all very personal, ironical or really weird.

Each consultant then told his/her career by moving his/her Lego custom figure over the big map, starting from some technology (e.g. C++) “in this continent” before “moving to another territory” (e.g. Java or .Net), then “crossing oceans” to gain additional skills in software factory and agile.

I particularly enjoyed the relaxed atmosphere, where anyone would interrupt to ask questions or comment, or throw a joke out loud. Perhaps the map, the Lego and the marshmallow made it clear that it was not too serious an exercise. The map and the Lego figures were able to make abstract skills more tangible and more fun for the time of the game.

We could have done the same exercise without all that, but the feedback we had from our consultants was very positive, they really enjoyed the game.

What’s next?

We’re going to put the big poster of the map on the wall, as a decoration. Smaller printed maps will help scope some discussions, perhaps for interviews, or when discussing with less technology-involved people. It could also be useful for developers to self-assert how much they know about the current state of the art in our craft.

Read More