#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!

#First

Well, it’s been some time since I wanted to create my own blog.

Even if I do already write on my company’s blog, this format doesn’t allow me to put some personal thoughts that much…

I wanted a place where I could dump things when I had the feeling I’d had to. Freely.

I went to the Craft Conference 2014 this week and it was so inspiring that it sounds clearly the right time to do so!

First blog post will obviously be about the Craft Conference but I hope you’ll find some other interesting readings (or not) pretty soon.

Thanks for reading!