Twenty-five years ago while a Civil Air Patrol cadet, I could get a cheap disposable camera, spend a week at camp, and take around twenty pictures “per roll.” I could then pay for a process called “developing the film” and after a three to four day wait, discover that only two or three photos were worth saving.
Today, taking pictures is essentially free. Free like water. Free like air. The device we use to take pictures is our ever present cell phone. If we would like, taking pictures can be about as commonplace as breathing.
It wasn’t that long ago that photography was a job, a solid, a respected one even, that took real technical skill. Today we still understand that the work of a photographer is well, work. We hire wedding and portrait photographers regularly. Journalists have cameras and take photos of their subjects as needed to tell a story. Yet the study of photography, as art, has declined. Which means people aren’t looking for beauty in the same way they might have been fifty, or even fifteen years ago.
Perhaps they should be.
It’s been exactly ten years since I published a two-part series on answering unfair questions. The first was general; the second was how to answer the question “why is testing always the bottleneck?” Ten years later, those questions are as relevant as ever. In fact, I’ve got that question coming from multiple directions right now.
The articles have aged well, and are worth a read — yet we’ve learned a thing to two in ten years.
Let’s talk about it. Continued »
Last month, I missed my train and had to drive into Chicago for work. While on the road, I used Google Maps for directions, SpotHero to pick out parking, and AirBnB to reserve a room. When I arrived in Chicago, I scanned my phone to get into the parking lot, which was about half the price of public parking. Checking in for AirBnB was as easy as using a code to access the building and another to get into my room. None of that was possible without a smart phone, and all of it was possible without talking to a single human being. Talk about your mobile workforce.
For dinner I could visit the Amazon Go store, about four blocks away. To enter a store, you bring up a QR code on the amazon app, let the turnstyle read it, and walk in. Then you pick your items and walk out. Proximity readers send a bill to your credit card.
Stop for a minute and think about the kind of mobile workforce this makes possible. Twenty-five years ago, you’d need to find the yellow pages for the city you were going to, or find a travel agent, or pay triple-A. You’d make plans days in advance, use maps printed on paper. You’d also pay too much for parking. Generally speaking, you’d get lost more and pay too much because you didn’t have enough options.
Still, it makes me wonder what we lost to gain so much. Continued »
Say you have a ticket for something. Permissions for Jira, or a database, or a password reset. The receiving team takes two days to look at the issue, only to determine they are the wrong group, and forward it to a different team, that takes two days …
If the receiving team says “That’s too big. we need to put it in our blacklog”, the answer could be two weeks. Or never.
Scheduling a meeting with an outside group can be worse. You suggest a meeting, two days later they reply asking for suggested dates and times. You reply, and four days later they write back that the first two dates have passed and the second two don’t work for them. So you reply again …
Here’s how to fix it. Continued »
Imagine you have an assembly line of finished product to inspect, but every product is different, and you know how. That means each ‘build’ will have different risks. So you can customize your inspection to address just those risks. Karen N Johnson recognized this ten years ago when she published RCRCRC – a set of guidelines for regression testing. Karen’s RCRCRC stood for Recent, Core, Risk, Configuration Sensitive, Repaired, and Chronic. That is, when you have to regression-test, prioritize those things, sort, and test until you run out of time.
It’s easy to poo-poo these ideas in this day and age of micro services and continuous delivery. On the other hand, let’s get real. Plenty of organizations can’t do continuous delivery, for plenty of reasons. Some of them test physical devices with hardware that is only updated once per year. Even with a firmware update, you kind of sort of want it to most work out of the box, right? Others are releasing to a store that may take days to a week to approve changes. Some simply have not developed the maturity to do continuous delivery well. After all, anyone can do continuous delivery of bugs and low uptime to production. It doesn’t mean they should.
Recently I worked on a project that used RCRCRC to mine for test ideas. Four continents, maybe 15 teams. The challenge was where to get the data. Here is my story. Continued »
You may be familiar with the idea of an “Agile Game.” These teach a concept, like the importance of feedback or teamwork. For example, David Hoppe and I once did a talk, “One Weird Trick to Improve Collaboration“, where we had people play a pair-programming game, or not, to see who could identify the capitals of all 50 states faster.
Today I’m going to describe the ultimate Agile Game, one invented a few years ago in Potsdam, Germany, at the Agile Testing Days Conference. The first time I played this game was with Tobias Geyer, Tamara De Paus, and Shachar Schiff as the secret agent.
Oh yes, there is a secret agent.
Here’s how to play.
Every few years there is a shift, where regular employees become consultants. Around fifteen years ago, it was frustrated employees becoming XP Coaches. Then it was employee to Scrum Master. Today people are moving toward “Agile Coaching.” I’m going to lump all these jobs into the space of consulting. On day one, the new shiny minted change-agents show up at the new job.
Then all hell breaks loose.
Two months later, over a beer at a local pub, the new consultant tells me a tale of woe. The tale usually begins with “it’s the strangest thing. You would think (thing one) and yet (thing two).”
Oddly it is often the same tale. At least, the same themes, over and over.
Here’s what to expect if you want to go consultant — and what to do about it.
If you want to get a group of new-to-each-other people to merge toward collaboration, I recommend lean coffee. If you want collective problem solving with no pre-planned agenda, based on the problems people bring and share, lean coffee is your jam. It can be done better or worse. Worse is fine, but better is fantastic.
It has been a pleasure of mine to present Lean Coffee at a few dozen events on a couple of continents.
Here’s how I do it. Continued »
No, not do they know a library, like selenium, or POI in Java to import Excel, or Cucumber, or Junit. I mean, can they actually take a problem and implement some code to solve that problem?
To do that, I used Katas.
It turns out that has problems. Continued »
FizzBuzz is a classic programming challenge, or “Kata“, popularized by Jeff Atwood, that requires the test-taker to demonstrate simple concepts like looping and selection. If you are active in the software world, you may know that it was popular at one time and has faced increasing criticism. One explanation for the decline of FizzBuzz is simple evolution. People just learned better interview techniques. Where Fizzbuzz was once the best we knew, today we know better.
I don’t buy it.
The typical programming interview is repeating a list of technologies and yes or no answers. Some teams use a contrived google style tech interview where navigate a binary tree.
A few companies do better, asking technical staff to pair, do TDD, or demonstrate expertise in other ways.
Here’s a way to do it with FizzBuzz.