Last year, when the Association for Software Testing announced the location for their next annual conference CAST 2015, Grand Rapids, MI, there was an up-roar happening on social media and back channels like Skype and private conversations. To my own surprise, I saw members of the context-driven testing community falling short of their very own principles. Rather than observing and interacting with people, it seemed that some persons preferred to derive their knowledge about Grand Rapids based upon a prior CAST conference there. Experience may be a good resource to start looking at, but I found that I should trust the folks from the local area that I knew to put together an awesome conference – more so since they could explain to me why the past experience was not so well received. When it came to the October 2014 AST board member meeting, Pete Walen, the conference chair, the guy who managed to send in a proposal prior to CAST 2014 so that the AST board could decide upon it, invited us to the conference location, so that it was easy to see for us where we were going with the proposal. Here is what I learned during my two nights in the conference venue – and why I think you should attend.
A while ago I considered adding some new type pf posts to my blog. There are many things that I notice in my leisure time at all the different spots that makes most folks wouldn’t think about, yet I see a relation to some of the stuff that I learned while diving into Agile software development. This blog entry kicks off these new type of posts.
I am not sure about other places on Earth, but in Germany the McDonald’s corporation recently started to re-design their restaurants. (Yes, I admit that at times a McDonald’s is one of my choices to take something to eat while switching trains.) They are now offering two types of counters together with a self-service counter using credit cards or bank cards. The in-person counters a split by the counter where you order and pay for your meal, and the counter where you can then pick your meal. Based upon subjective experiences, I think this move is a dramatic move away from customer friendliness.
What’s the problem?
My observation into many of these encounters was, that I needed to wait way longer to get food than it was the case before this re-design. Waiting times used to annoying to us customers even in the old design, but now with the new design, things got worse according to my personal experiences. Of course, it’s not much of a problem if there are few other customers. But imagine the situation when a full train arrives with hundreds of passengers during lunchtime at a local train station. Some of them at least will walk into the nearest McDonald’s to grab some food.
In the old workflow design, there were usually three to five counters open during such high times. There were several queues forming in front of these counters, you would be waiting in line for your turn, order, pay, wait for your meal to be prepared, and then leave. Overall this had been between 5-15 minutes at times for me.
Now let’s take a look at the new workflow design. You enter the restaurant, see two open counters with lots of folks waiting there, and you see the full list of already ordered meals on the screen above the counter for the pick-up. If you’re like me you check the self-service machines in such case. Funny thing is that in 95% of the times I ran into such a situation, these were out of order.
So, we get in line in front of the in-person counters. We wait until it’s our turn, order, pay, and receive a receipt with a number for the pick-up counter. There you queue up until it’s your turn to pick up your meal. But wait, there is only one guy serving the pick-up counter. So, all the customers from the two in-person order counters end up in a single queue to get their food. It would be even worse if one or more of the three self-service machines worked.
What’s happening here?
As Mary Poppendieck taught me a while ago, whenever there is a queue, there is certainly sub-optimization happening. What’s the sub-optimization here? McDonald’s seems to optimize for cash-flows and sparing personell costs from my point of view. Two in-person counters, and one guy serving the meals is three quarters of the salary they used to pay before the re-design.
Of course, people wouldn’t buy into that without some benefits. The self-service machines and the new fancy restaurant layout seem to be the selling points here. But it seems that they have under-estimated the demand and the necessary queues for such a move.
So, what’s better about the old system?
Did you notice the hand-off between the two counters? Yeah, I think this is the major culprit. On face value, you saved one person’s salary with the new workflow. On the other hand, you made it way harder for people to support each other.
Consider this situation that I observed last week. The pick-up counter was heavily under stress with 5-10 items still in line. At some point one of the in-person counters clerks decided to help them out, move from the counter, and got into the kitchen. Unfortunately the other cashier also had to leave for some reason I didn’t get. I observed five new customers stepping into the restaurant totally confused about where to get food, since none of the cashier stations was served.
The problem is that the new workflow makes it close to impossible for other people in the restaurant to help out the current bottleneck in the overall system. In the past I have observed folks from McCafe stepping in to help out others if there was a need. Now, it’s impossible.
All of this came with the specialization that slipped into the workflow from separating cashing and food preparations. The one additional hand-off made it less likely for me personally to enter a McDonald’s restaurant if I want to use my 15 minutes train switching time to grab something to eat. Maybe my wife will like this in the long, but on face value, I think McDonald’s harmed their overall business more than necessary with this one additional hand-off and specialization that happened alongside.
I certainly don’t know any business numbers from McDonald’s, but I imagine that client happiness with the new workflow restaurants dropped dramatically probably resulting in fewer returning customers.
Now, think what happened when the software industry introduced hand-offs between Analysis, Design, Architecture, Coding, and Testing.
Every once in a while I read something like this:
Yeah, [TDD|BDD|ATDD] is great. But how do you convince [your manager|your employer|your colleagues] to get the time to do it?
In the past week I decided that I need something to point folks to when this questions comes up again. So, here it is.
Continue reading How to sell TDD to <x>?
Since I am publishing this on my personal blog, this is my personal view, the view of Markus Gärtner as an individual.
I think the first time I came across ISO 29119 discussion was during the Agile Testing Days 2010, and probably also during Stuart Reid’s keynote at EuroSTAR 2010. Remembering back that particular keynote, I think he was visibly nervous during his whole talk, eventually delivering nothing worth of a keynote. Yeah, I am still disappointed by that keynote four years later.
Recently ISO 29119 started to be heavily debated in one of the communities I am involved in. Since I think that others have expressed their thoughts on the matter more eloquently and deeper than I going to do, make sure to look further than my blog for a complete picture of the whole discussion. I am going to share my current state of thoughts here.
The other day, I sat down Kishen Simbhoedatpanday in order to talk about ATDD, and eventually an upcoming class on the implementation side of ATDD. We talked about maintainable tests, and how you could refactor tests to yield better tests. Gojko wrote about the anatomy of a good acceptance test a while back, and I think we can be more explicit here. Then it struck me. The Single Responsibility Principle also applies to your automated examples – and why that’s the case. You just need to think on a conceptual level about it. Mixing business domain concerns with application concerns in your examples – and sometimes even with driver concerns (think Selenium) – is a terrible thing to do.
Let’s explore this idea further.
The agile community is full of stuff on generalists. Ideally, you should be able to juggle coffees for your developers while riding a one-wheeler, and playing the guitar to “Master of Puppets” from Metallica at the same time. Oh, and you really should have found that bug while doing all that.
That’s a task close to impossible. Let’s take a step back, and take a look into another field of work: cooking. How do you react to generalists there? Let’s see.
Caution: Before reading on, make sure, you had enough to eat. (Or didn’t, depending on how fast you can get weak.) This blog post includes references to lots of yummy meals, and contains itself 2000 kcal.
On Sunday, while writing the blog entry for Monday, I tweeted (or is that ‘twoted’?):
One of these days I’m going to write a blog entry on how I write blog entries. You are going to be surprised.
That cliffhanger triggered some responses from people that wanted to know more. So, I took the writing process of my Tuesday’s blog entry as an example to describe the process of me writing a blog entry.
I hope you are not going to hate me after reading this.
A couple of years ago I read a book from Michael Feathers that kept on being mentioned a lot in the literature I was reading then. The title? Working effectively with legacy code. Feathers makes some points on how to get code without tests working, by breaking down dependencies, introducing seams, and working towards more testable code. I loved that book.
When we take the idea of test automation as software development seriously, then there also should be a concept called legacy tests. That concept to me is related to testing debt, a term I think I coined back in 2009. But what are legacy tests? How do they slow down your productivity? And what can we do about it?
Here are some limited experiences I made with a couple of legacy tests, and how to overcome them. I hope this blog entry will trigger some more experience reports from folks, so that fewer teams need to suffer from it.
In his book, Thinking fast and slow, Daniel Kahneman explained the concept of Sunken Costs to me. I found this concept powerful and interesting. But only recently I discovered the many costs that can be sunken. Here’s a brief summary for costs involved in software development.