Monday, March 13, 2017

Why we did a speed meet at our conference and why you should too!

At European Testing Conference 2017, we had a full session devoted to a speed meet.

What is a speed meet? At its most basic it's talking to someone new for 5 minutes, then rotating and doing it again 9 times.

Here's what it looked like:

Mind Maps: What do you talk about?

Of course this raises the question of what to talk about? To solve this, we took a suggestion from  Jurgen Appelo and had everyone make a small mindmap about themselves. When you sat down you handed your map to the other person. Therre is a lot of information between the 2 mind maps and people would easily find something that they were interested in. And this is the rather amazing thing about geeks; 

5 minutes to make small talk is terrifying for geeks.
Given a topic they care about 5 hours isn't enough time

Here's an example of one of the participants mind maps:

Why do this?

Conferences are amazing places. It's a great opportunity to mix and talk with many people you wouldn't normally get a chance to interact with. However, if you are new to a conference this can be a overwhelming and terrifying prospect. While most people are friendly after you meet them, strangers never seem that way. We wanted to make it easier to have a good 'hallway track'. After talking to 9 people everyone had at found at least 1 person they liked.  The conference became a lot more friendly. We also heard more things like:

"Kara! Have you met Matt?"


Lunch time can be especially uncomfortable if you don't know anyone at a conference. Finding a place when every table is full of strangers already talking? Often we can just try to find a place to hide away and eat quietly. This is why we did the speed met in the morning the first day of the conference. Lunch was right afterwards, and it was nice to know at least 1 person to eat with.
lunch should be friendly, not scary


Just do it

Structure and lack of choice is your friend here. Notice that while we normally had 3 tracks, we only had 1 during the speed meet. We didn't want to encourage people to skip it. We also spoke to the speakers to encourage them to participate. It can be a special treat for a newbie to get a chance to speak 1 on 1 with a presenter. 
We also didn't do it as an 'optional' morning session. These sessions usually have a very low percentage of the conference attending. For example, many conferences have a lean coffee morning session. But, for a 1000 person conference it isn't unusual to have 20-30 people at these. 


We gave multiple chances to create the mind maps beforehand 

  • Emailed the day before conference
  • Mentioned at Speakers dinner
  • Mentioned in opening slides for the conference
Nonetheless, there are still a bunch of people how put theirs together as the sessions started. That's ok, it's meant to be quick and easy. We provided lots of paper and pens.


I highly suggest a few (4-5) practice rounds of moving 1 seat to the left. It's amazing that if you wait for the seat next to you to become empty ( X 150 people) this can take a few minutes to move people. If everyone stands, moves & sits it takes 3 seconds.  


This sets the tone for the conference. Do it early, not at the end of the conference.

How did it work out?

Excellence! It can be hard to judge the effectiveness of an activity. We do a retrospective and we got many notes about liking it, but is liking it the same as it being good? Maybe they just remember it because it was different?
I had a bit of an advantage as this is the second year for ETC and we could compare it to last year. I also have all the other conference I attend to compare it with.
However, the biggest indicator for me was the party the first night. While it's hard to articulate, it just felt friendlier. People moved between tables more, talked more. The whole atmosphere felt warmer. 

10 / 10 Would repeat!

Wednesday, February 1, 2017

Thoughts on conference design

Next week is the European Testing Conference. 
We do a lot of things to make this conference better 

European Testing Conference
Feb  9th & 10th  (Pre-conference Trainings on the 8th)
Helsinki, Finland
25% off discount code: FRIENDSOFLLEW

Here are some of the things we do to make a better conference for the attendees:

1)   Facilitate meeting other people
We all know that one of the best parts of conferences is the people you meet but it can be hard to strike up a conversation with complete strangers. 
Knowing this, we set up 2 events structured to introduce you to new people.
a)    Speed Meeting:
This occurs at 11:00 the first day and is the only session at that time. The whole conference sits and talks to a new person for 5 minutes. Then rotates and does it again. 45 minutes later, you have talked to 9 new people. Sometimes that is enough to help you find the right person, sometimes it’s one of friends of those 12 that you get introduced to. Either way the conference becomes a lot friendlier afterwards.
b)   Facilitated Discussion
Later that day we will do on other 45 minutes of round table discussions (8 people per table). This will follow the lean coffee format and allows people to talk about the subjects they are interested in with each other. It is also a chance to speak with the speakers your are interested in, as each speaker will facilitate one table.

2)   Workshops
One of the challenging things about workshops is it’s hard to actually go to them when there is the easier choice of just listening to a talk. The lazy part of us wins out so much of the time despite our best intentions. Know this, when never run the workshops sessions at the same time as normal lecture sessions. So you don’t have to decide *if* you do some hands on learning, you only have to decide which one you want to do.

3)   Hallway track
Meeting new people and doing hands on learning has a way of stirring up ideas. Many experienced conference goers talk about the ‘Hallway Track’ as valuable part of conferences but new people often are let out on this aspect. Knowing this, at 14:15 on the last day, we set aside 3 sessions of open space, where you can announce the topics you’re interested in and then hold mini-sessions with like minded people. This helps in ensure everybody gets the most out of the new ideas they have had.

We hope you agree that these steps help to create a better conference and hope to see you there!

We also do a lot to make it better for the speakers, but that's another blog post.

Monday, January 9, 2017

Is there a perfect API Design?

Part I:The Problem

I write a verification framework called ApprovalTests. It uses itself to test itself and is generally bug free. So when exploratory tester extraordinaire Maaret Pyhäjärvi wanted to use it as a test target we were both rather excited. I was excited to show off how good automated testing and TDD can be. She was excited to show off how much it still failed to cover.

She won.

To be clear, the stuff I tested was pretty solid. However, I was woefully incomplete on the system as a whole. A mere hour of testing discovered gaping holes in different environments, documentation and onboarding of new users, and usability issues with my API.

These are hard problems, many of them still haven't been solved and I wanted to talk about one in particular that I am still struggling with today:


I use something called reporters and annotations in ApprovalTests. It means you can write code like


The issue was in discoverability. If you start typing this you get very little help from your editor:

You get some other reporters [KDiff, Tortoise] but not many and these happen to be useless and DiffReporter will use them if they exist on your system anyways.

If you typed "Reporter" instead this goes away and the over 50 options will present themselves to you, but it's not intuitive to this and a few painful usability tests showed this to me over and over as I watch is silence and frustration.

Renaming can fix this


I ran an online poll, most people preferred this. 70% vs the 30% that preferred the previous version.
I think I'm in the 30%, I prefer my classes to have Noun names, but I might be partial because this is what I'm used to.

So I'm faced with changing a lot of the API.

The issue is:

How do I know which one is the right answer?

How do I know there *is* a right answer?

Part II: 2 Pepsis and the world of choice

Malcolm Gladwell did a great Ted Talk on choice. In it he talks about a taste test to find the perfect sweetness for Pepsi. There were 2 peaks, so they averaged them out, but this isn't the right answer, the right answer is there are 2 preferences for sweetness. Because of this as a culture we have changed from a single 'perfect' spaghetti sauce to an aisle of choices

Maybe we should have the same occur with API's?
Maybe the issue isn't to have either UseReporter or OnFailure. Maybe I need to have both.

This requires a bit of finesse. I don't yet have answers on how to version and package these solutions.
Should they be in separate nuget packages? Should they interplay with each other?
How to I balance having a clear way with choice paralysis.

I don't know the answers to these questions, but I am beginning to see that maybe there isn't the one perfect API...

Saturday, July 30, 2016

5 ways to do Decision trees in C#

At Agile2016 we spent the mornings doing Mob Programming working on the Tennis Refactoring Kata from Emily Bache.

Thursday we ran accross this issue:

#1. If Structure

This is fairly easy to code as is, the trouble is it looks horrible:

So we started to play around with alternative structures...

#2. Pass in result

One solution is to call all the methods but abort early if you've already found a solution.
This looks a lot nicer, the problem is it leaks into the underlying methods
So we keep looking..

#3. Linq

If you like linq you can solve this with a bit of functional code

This reads nicely, but is a bit confusing as to why it works and means all your methods must not use any parameters.

but It can also be used with the yield keyword, which is neat and allows parameters but splits logic.
so we kept looking...

#4. Do If Null

We were able to get closer to the 'Pass in result' without leaking with the addition of an extension method.
at this point someone pointed out the ?? operator...

#5. ?? Operator

The ( a ?? b ) operator says if  a is null do b. The resulting code is rather nice
It's worth noting that if your language has 'truthiness' (like javascript) you can also do this with the or (||) operator

Which is Best?

Of course that's up to you. For us most liked the ?? operator best, while a few thought the Linq solution was the nicest.

Which one do you like? 

Wednesday, June 15, 2016

Interview with Bryan Beecham about Pairing w/me the first time

I put a interview Maaret recorded with Bryan Beecham online yesterday.
It's about the first time Bryan paired with me using Strong-Style Pairing.

Here's the video:

and the Transcript:

 So the first time i met llewellyn I was in a session at an agile conference. They were talking about a developer and tester pairing and the benefits of that and it was a great session and the really cool thing was that it was very hands on so I ended up pairing at a table and I had this guy. This guy there with like kinda a little cocky he's got blue hair and I'm pairing with him. And I'm like great, I'll learn. I know how to code a bit... but we are using eclipse (i think) and I don't know eclipse that well... and he asked me that, maybe he noticed my hesitation and he said how well do you know this IDE?
 and I said "ah, it's not my thing"
 and he said "that's ok, because I'm going to tell you what to type."
   and I thought maybe he thinks I'm new to pair programming or something and I don't know about this but no, I was in for a whole new world of understanding because the person, who turned out to be llewellyn, introduced me to some, I guess now it's been modified to strong pairing which has some other meanings to it, but he told me what to do and told me what to type and when you think  
 oh yeah, type something very high high level, but no he was telling me on a very low level of type this word. press enter press semicolon you need a curly brace there and I was not allowed to use the mouse it's like no, no no no it's
 alt+r for that
and word by word, but I'm like 'keep it cool' 'keep it cool' because inside i'm about to boil over and just be furious, right, but then I noticed something was happening.

  I was noticing that I started to know what extract method was I started to pickup on somethings I started to understand the syntax better and his language started changing as this happened and he started talking at a more abstract level and his instructions got moved to a higher level and we were actually picking up speed and I was like 'holy smokes there's something to this' so although he's like completely obnoxious and annoying at first that there's really something here.

  So I that was my introduction to Llewellyn and I would like to say that as this point I feel like he is becoming a  very good good friend of mine  

Friday, June 3, 2016

Using intellisense for documentation

A few days ago I created an open source project called EclipseTips with help from Aki Salmi

It's a small jar that has classes without implementation that provide useful cheat sheet hints while you are working.

Here's what it looks like

The really interesting thing about this is it is a hack about using editor inline help solely for the purposes of help. This is something I have not seen done before.

Keep in mind that these java classes serve no purpose other than to provide documentation.

Because this is a new area, I wanted to share some lessons learned as well as places I think this could be expanded to.

Lessons Learned from version 1

Hack then Generate

Javadocs is a reasonable place to add documentation when coding, but it is not a good place write real documentation. Once you get the general idea and a few working prototypes, you are going to want to create a way to generate the documentation classes.  

For example, here's how we created the Completions Tips data. We then generated both the mac and windows tip objects from here.

You can take a full look at the generation process here.

Simple Html

While the documentation rendering doesn't support much, you can use simple html like tables and images and UTF8 characters to make your text more readable. Just keep it simple.

Use tl;dr curation

A lot of the value is in the discoverability and quick readability. We approached this in a couple ways.
  • We don't show all the tips, only the ones we judge 'most' useful
  • We grouped things so you could focus on pieces, but we also had a full listing under .Mac()
  • We named the groups starting with an underscore ( _Lines ) so they would be together in the editor

Possible Next Steps

Other Editors

  • Visual Studio / Resharper (for vs keybindings & R# keybindings)
  • IntelliJ

Example / Starter / Cookbooks for Api

When you are getting started you often find your way to websites to lookup quick getting started examples. This as stuff that doesn't exactly belong in the actual code itself. Especially as the examples might be how you discover the packages, class and methods you want to call.

I could easily see documentation classes for things like linq, unit testing, markdown, regex, etc.

Of course, you might want to put that directly on the methods (as documentation was originally intended) but this also opens up the ability to write a documentation project for a project you don't actually own yourself.

Let's see what the future will hold...

I'm excited to see what will come out of this discovery. If you have ideas please reach out to me on twitter ( @LlewellynFalco ) Share what you've created, or ping me and we can pair and create it together.

Tuesday, March 22, 2016

The coordination tax of working alone

If you have team members working together on a project but separately on their own piece of the project then you need to coordinate that work.

There are lots of interestingly different ideas on how much 'cost' there is to this coordination. Ranging from it's a very low overhead, to it requires a full time manager who is the highest paid person on the team. Often these drastically different opinions are held on the same teams by the same people.

What I want to explore today however is what does the actual coordination looks like and what it would mean to get it right.

To start off with, there are a few types of coordination:

Multi-functional coordination

If someone is building the database and someone is building the UI those things need to talk to each other; usually through a middleware build by a third person. If they don't line up the costs are large indeed, ranging from "we need to redo this" to the far worse "Let's ship the wrong thing". 

The coordination includes:
  • knowing what each piece looks like
  • which functionality goes where
  • how to connect them
If you know the answers to all of this, then I believe you can make a fairly good assembly line fashion process. 

However, I would like to state categorically 
"If you have not yet built it, you don't know everything involved"

or as the great Woody Zuill said

"It's in the doing of the work that we discover the work that needs to be done"

And I don't mean done 'something like it'. If you've ever done a remodel on your house you will notice the estimates don't match the end result. It's not that this is the first remodel the contractor has ever done. Each situation has it own unique unknown unknowns.

Unfortunately, in software we are always doing something new because duplication is a copy and paste away.

Coordination of these types of tasks is expensive. You need an level of detail and level of oversight that is time consuming to obtain. If you don't get it right there is a lot of waste in the process that is silent.

Multi-person coordination

Even if you have people with the exact same skill set you will often have them working separately in an effort to maximize throughput. Here the coordination is in reducing duplication and keeping the code united. You don't want different people creating the same things or worst the same things in a different way where it's hard to realize they are even the same things. Ideally you want everyone producing unique work in the best possible way.

Perfect coordination 

I think perfect coordination is easiest to picture in a single entity. This entity is aware of the details and the larger picture. It has the skill sets for all aspects of the code. It incorporates new knowledge and processes  the moment it learns them. It has a memory of the previous work and knows when it should reuse pieces. It has high self awareness and doesn't have to spend a lot of time in meeting talking about work.

For many small projects this entity has been a single person.

I hypothesise that it is also the reason a Mob can be effective.