Wednesday, July 26, 2017

Making a conference talk practical (for me)

I've again had the annual pleasure of talking *amazing* people from around the world, both seasoned speakers and new, and get inspired by their stories. It pains me to know that a small percentage of all the awesome people can be selected, and that our specific selection criteria of practical relevance makes it even harder for many people. Simultaneously, I'm delighted to realize that while I may say no on behalf of European Testing Conference 2018, I could help those people make their proposals stronger for other conferences.

Today, however, I wanted to write down my thoughts on what is a talk that is practical, to me.

I've had the pleasure of listening to lots of presenters on lots of topics, and over time, I've started recognizing patterns. There's one typical talk type, usually around themes such as security testing, performance testing, test automation and shifting work left that I've categorized into a talk about importance of a thing. This is one where the core message is selling an idea: "bringing testers into the whole lifecycle in agile is important". "Test automation is hard and important". "Performance testing continuously is important".

I get this. Important. But I know this. My question is, if it is important, what do I do. So here are stories I'd rather hear that make this practical.

1) I sort of knew X was important,  but we did not do it. We failed this way. And after we failed, we learned. This is specifically what we learned and how we approached solving the problem. So, learn from my mistakes and make your own.

2) I'm an expert in X, and you may be an expert or a novice. But if you try doing X, you could try doing this specific thing in X in this way, because I find that it has been helpful.  This answers your questions of how after quickly introducing what and enables you to leave this conference knowing what you can do, not just that you will need to do something.

3) Here's a concept I run into. Here's how I applied it in my project, and here's what changed. Here's some other concepts we're thinking of trying out next.

Assume important or necessary is a prerequisite. What would you say in your talk then? 

Tuesday, July 25, 2017

Greedy Speakers are the Death of conferences

Conference organizing is hard work. Lots of hours. Stress over risks. '

But it's also great and amazing. Bringing people together to learn and network makes me feel like I'm making a small difference in the world.

And for me in 2017 it has also been losing some tens of thousands of euros on organizing a conference that was totally worth the investment, regardless. 

I organize conferences idealistically. My ideology is two-fold: 
  1. I want to change the world of conferences so that money isn't blocking the voices from getting to stage. 
  2. I want to raise money to do more good by supporting speakers for conferences that don't pay the speakers.
I also organize without raising money, and I've made organizing without any money a form of art for myself in the last 15 years. But that's local meetups, and I do a lot of them. I have four coming up in the next month. 

I'm tired of conferences, where majority of speakers are vendors, because they have an interest in paying for the speaking. I want to hear from practitioners, and sometimes consultants if they keep the selling to a minimum. Bottom line is that all speakers have something to sell anyway, their personal brand if nothing else.

I would like to believe that conference going is not a zero sum game, where choosing one is away from the other. People need places where to share, and there's a lot of people to listen to various perspectives. But I also feel that people need to make choices in which conference they go to, with their limited budget. Cheap conferences are great, it enables your organization to send more people out. But conferences are cheap if the money comes elsewhere. And this elsewhere is sponsors and speakers as sponsors, paying their own way to work for the conference.

Being able to afford the cost is a privilege not everyone has. I would like to see that change and thus support the idea of Not Paying to Speak at Conferences. And this means travel + hotel paid. No fancy expense accounts, not even paying for the hours of work to put into the talk you're delivering, but taking away the direct cost.

Conferences that don't pay but yet seek non-local voices have made a choice of asking their speakers to sponsor them and/or the audience (if truly low-cost). If they're explicit about it, fine.

The could choose to seek local voices so that travel and expenses are not relevant. But they want to serve the local community with people's voices that travel, and people (who can afford the travel in the first place) have the freedom to make that choice. The local community never has a chance of hearing from someone who won't travel. They haven't heard that voice before, and still won't. And the ones who can't afford (I was one!) can be proud and choose to remain local, rather than go begging for special treatment. Some people don't mind asking.

I wrote all of this to comment on a tweet:
I've been told that travel expenses for the speakers and in particular paying the speakers is the death of commercial conferences too. They need to pay the organizers salaries. It's a choice of ticket pricing and who gets paid first. Local conferences don't die for travel expenses, if they work with local speakers. But they tend to like to reach out to "names" that could bring news from elsewhere to this local community.

The assumption is that a higher ticket price is death of a conference. It's based on the idea that people don't value (with money) the training they're receiving. Perhaps that is where the change needs to be - expecting free meals.

I can wholeheartedly support this: 
Do that even if you're not a first time speaker. There's nothing wrong with building your local community through sharing. It might give you more than the international arenas.

Greedy speakers are not the death of conferences. There's conferences with hugely expensive professional speakers that cost loads, and still fill up. If anything is death of conferences, it's the idea that people are so used to getting conferences free that they don't pay what the real cost of organizing a *training* oriented conference is.

Luckily we have open spaces where everyone is equal and pays. We're all speakers, all participants. Conferring can happen without allocated speakers, as people meet.

Saturday, July 22, 2017

A Team Member with Testing Emphasis

Browsing Twitter, I came across a thought-provoking tweet:
Liz Keogh is amazing in more ways that I can start explaining, and in my book she is a programmer who is decent (good even) at testing. And she understands there's still more - the blind spots she needs someone else for. Someone else who thinks deeply and inquisitively. Someone else who explores without the blind spots she has developed while creating the code to work the way it's supposed to.

Liz is what I would call a "team member with programming emphasis". When asked to identify herself, no matter how much she tests, she will identify as a programmer. But she is also a tester. And many other things.

Personally I've identified as a "team member with a testing emphasis". That has been a long growth from understanding why would someone like Ken Schwaber years and years ago suggest to my manager that I - who want to be a tester - should be fired. Over thinking about it, I've come to the conclusion that this is one of the ways to emphasize two things:

  1. We are all developers - programmers, testers and many others 
  2. We need to work also outside the focus silos when necessary or beneficial
For years, I did not care so much for programming so I found a way to call myself that I was more comfortable with than a "developer" which still is loaded heavily on programming. I became a self-appointed team member with a testing emphasis.

This works still, as I've grown more outside my tester box and taken on programmer tasks. It means that while I code (even extensively, even production code not just test code) the tester in me never leaves. Just like the programmer in Liz never leaves. 

Liz can be a brilliant tester she is in addition. And I can be a brilliant programmer I intend to be. And yet she can still be the programmer, and I can still be the tester. 20+ years of learning allows growth outside the boxes.  But it's still good to remember how we got here. 

If software industry doubles every five years, half of us have less than five years of experience. Perhaps it makes sense to learn a good foundation, starting from different angles and build on it. 

Individuals make teams. And teams are stronger with diversity of skills and viewpoints. 

Automation tests worth maintaining

A retrospective was on it's way. Post-it's with Keep / Drop / Try were added as we discussed together the perspectives. I stood a little on the side, being the loud one, leaving room for other people's voices. And then one voice spoke out, attaching a post-it on the wall:

"It's so great we have full test automation for this feature"

My mind races. Sure, it's great. But the automation we have covers nothing. While creating it for the basic cases, we found two problems. The first one was about the API we were using being overly sensitive to short names, and adding any of those completely messed up the functionality. I'm still not happy that the "fix" is to prevent short names that otherwise can  be used. And the second one was around timing when changing many things. To see things positively, the second one is a typical sweet spot for automation to find for us. But since then, these tests have been running, finding nothing.

Meanwhile, I had just started exploring. The number of issues was running somewhere around 30, including the announce of the "fix" that made the system inconsistent and I still deem as a lazy fix.

I said nothing but my mind has been racing ever since. How can we have such differences of perspectives on how awesome and complete the automation is? The more "full" it's deemed, the more it annoys me. I seek useful, appropriate and in particular over longer time not just on time of creation.  I don't believe full coverage is what we seek.

I know what the automated tests test, and I often use those as part of my explorations. There's a thing that enables me to create lists of various contents in various numbers, and I quite prefer generating over manually typing this stuff. There's simple cases of each basic feature, that I can run with scripts and add then manually aspects to what I want to verify in exploration. I write a lot of code, extend what is there but I rarely check in what I have - only if there was an insight I want to keep monitoring for the longer term future.

Cleaning up scripts and making them readable is work. Maintaining them when they exist is work. And I want to invest in that work when I believe the investment is worthwhile.

The reason I started to tell this story is that I keep thinking that we do a lot of harm with the "manual" vs. "automated" testing dichotomy. My tests tend to be both. Manual (thinking) is what creates my automation. Automation (using tools and scripts) is what extends my reach in data and time.

Tests worth maintaining is what most people think with test automation. And I have my share of experience of that through experimenting with automation on various levels. 

Wednesday, July 12, 2017

Is Mob Programming just Strong-style Randori?

Back in the days before Mob Programming was a thing, there was a way of deliberate practice referred to as Randori. The idea there was pretty much similar to what the mechanics of mobbing are. There would be a pair out of a group working at a time on a problem, and then you'd rotate.

My first Randori experience was a long time before I ever heard someone was working in this "mob programming" style, and on a shallow level, the difference I saw from my first introductions to mob programming was the use of strong style navigation. So the question emerged: is mob programming really just a strong-style Randori?

I'm blogging since being reminded:
Pool is not just a bigger bath tub.
Surely, pool is a container with water in it. So is a bath tub. But the things you can do with a pool are significantly different from the things you can do with a bath tub.

Examples popped out: there's such a thing as a pool guard, but it would make no sense to have a tub guard. Pool parties are a thing, but you might argue that a tub party is a very different thing. The physical exercise aspects of pools are non-existent in tubs, you wouldn't really say you swim in a tub.

While it is a fun word game to make one think, it is a good way of illustrating why mob programming is not just a Strong-style randori. What mob programming as Woody Zuill and his team introduced it brings in is hundreds of hours of learning while continuously collaborating, and with that communication some of the problems we see no ways of making go away just vanishing.

Doing things over long time to grow together make it different. Mob Programming is different.

And the same applies to many of the things where we like to say that this "has been around for ever". Test after and test first are essentially different. The things we can do with continuous delivery are essentially different to just continuous integration.