In this Episode
Rich Rogers is the author of the Leanpub book Changing Times: Quality for Humans in a Digital Age. In this interview, Leanpub co-founder Len Epp talks with Rich about his background, working on a merger from within a big organization, moving to Australia, software testing, his book, and at the end, they talk a little bit about his experience as a self-published author.
This interview was recorded on September 1, 2017.
This interview has been edited for conciseness and clarity.
A Note About the Leanpub Frontmatter Podcast
This summer we split the old Leanpub podcast into two distinct podcasts:
Frontmatter, which is a general interest podcast where you can listen to Leanpub authors talk with Leanpub co-founder Len Epp about their books and their areas of expertise, from data science to molecular biology, to the history of labor and management. And for those interested in the nitty-gritty of what it takes to be a successful self-published author, at the end of each episode Len asks the author about how they made their book and how they are spreading the word, and other publishing shop talk.
Backmatter, a new podcast focused specifically on the publishing industry and its latest trends. In each episode Len interviews a professional from the publishing world about their background and their insider's perspective on what's happening in the huge and evolving world of book publishing.
A Leanpub Frontmatter Podcast Interview with Rich Rogers, Author of Changing Times: Quality for Humans in a Digital Age
Len: Hi, I'm Len Epp from Leanpub, and in this episode of the Frontmatter Podcast, I'll be interviewing Rich Rogers.
Rich is a software and technology testing and quality consultant based in Sydney, and the author of, Changing Times: Quality for Humans in a Digital Age, which he recently published on Leanpub.
His book considers the relationship between people and technology, and not exactly in the genre typical of books that address this topic, the genre publishers refer to as "prescriptive non-fiction," that makes up the majority of technical books published on Leanpub.
Well, it does have a lot of prescriptive non-fiction and excellent information in it and advice, but the book is structured around a fictional story of a journalist named Kim, and her relationship with the technology that has an impact on her life.
In this interview, we're going to talk about Rich's professional interests, his book, and at the end, we'll talk a little bit about his experience as a self-published writer and author.
So, thank you Rich for being on the Frontmatter Podcast.
Rich: Thank you very much for having me.
Len: As I think you know, I usually like to start these interviews by asking people for their origin story. I gathered from the prefix to your book that your interest in software and technology generally goes back to your early childhood, and I was wondering if you could talk a little bit about how you first got interested in computers and technology?
Rich: Sure. As I mention in the book, as a child growing up in the UK in the 1980s, I became interested in technology from the point of view of, how can it help people? I mention examples like calculators and VCRs and home computers. They were the kind of things that really sort of caught my interest. I guess what maybe makes me slightly different to some in the field, is that my interest was in how those things could help people, rather than how they worked. I wasn't someone who took calculators apart to see the internal workings. I was more interested in the ways I could help people.
That's kind of followed through in my career. I've worked in software development for over 20 years. Most of that time, as a tester - or involved in testing to some extent - I've really been interested in the way technology helps people. I think that's a really important thing for testers to keep in mind. But it's really something that's played out through my career.
As I wrote the book, I really wanted to focus on that aspect of technology, how it could help people. And also, how people were involved in creating technology and what it meant to the people involved in software development and the broader technology world.
Len: Did you study computer science in university?
Rich: I did some computer science at school. I had a home computer, and we did some programming and coding at home. Very, very basic coding. I actually had an Acorn Electron, which is a bit of an obscure computer. Most kids had Spectrums or Commodore 64s. We had an Acorn Electron, which used BBC Basic. My brother and I learned how to write some simple code on there. Mostly we just played games, but we did do some coding. And then through computer science in school, I learned a bit more, and then took that on into university.
The course I did at university was called a Business and Technology course, so it wasn't purely a course to learn about computer science. It was very focused on the applications of technology, and the applications of computers in the business world. It had a balance between the technical side and the real world application.
Len: I have a specific question about business and technology that I'm going to ask you in a couple of minutes. But before jumping ahead, I wanted to ask how you got into testing?
Rich: I was very fortunate when I left university. I had a friend who's mother was Director of a software development company, and I had a chat with her. They were keen to bring in some graduates, and I took a job with them. I think at that time, they were needing to increase their testing capability. They had lots of people coming in doing development work, but they needed to grow their testing team. I hadn't particularly selected testing as a discipline I wanted to be involved in, but it was a good place for me to start my career, and I really enjoyed it.
It just became something where I really felt that I could get a good all-round understanding of the products that I tested, and how they were used. Over time I started to really develop that interest in testing, and the different ways that testing was performed.
Of course, working in different industries and for different companies, there were very different approaches to testing. Some very, very large scale operations, some very procedural testing operations, some more exploratory. Certainly in the early stages of my career, I think that there was less procedure and more exploration involved in testing.
It became a real passion of mine, and I guess associated with that, I got to see the quality of software that was actually delivered. I got to see some of the decisions that went into whether quality was fit to be shipped. That was the really interesting thing as well. I don't necessarily believe that it's a tester’s role to make those decisions. But you certainly get an indication of how those decisions are made as a tester.
Len: I know this next question has many answers to it, but maybe you could start with an example of your first testing job? What does a tester of your category do? Most people are probably familiar with the idea of say a video game tester, who - let's say it's a racing game. They tell you to floor it and pull to the right, and just hit the edge of the track for an hour straight, and see what happens. Try to break things that you're interacting with game-style. When you were first getting started, when there weren't necessarily so many processors or things like that, how did you go about testing, and what kinds of things were you testing?
Rich: The first company I worked for was a company called Paradigm. They created software for manufacturing organisations. So, it controlled some of the machinery in factories, and it also was involved in logistics and delivery planning, that side of things.
You used a very interesting phrase when you asked that question there about seeing how things work. And I think that's sometimes something that is lost in testing.
Good testers do tend to approach things from the point of view of learning about them and understanding how they work. What has tended to happen with testing, is that it's become far more rigid and specification- or requirement-based - confirming the requirements have been met, rather than thinking about, how does this thing actually work?
So my philosophy, certainly in the early days, was very much around getting an understanding of whatever it was I was testing, and learning about it and providing information on it. I think I probably lost that for part of my career. I think many testers will say the same thing. They kind of got pulled into this world of doing things in a very regimented and procedural way. For me, testing is about providing information to people, and doing that through learning and exploring whatever it is that you're testing.
Len: Circling back to what I mentioned before, I had a question related to business and IT. One thing that I saw from your LinkedIn profile when I was researching for this interview, was that you worked on the integration program for the Lloyds TSB and HBOS merger back in the day. In a former life, I was an investment banker in London, and I left just before this infamous merger happened.
A little bit of background for people listening. Around the time the credit crunch was turning into the Great Recession, and investment banks were collapsing, the Bank of Scotland ran into a bit of trouble, and was acquired by Lloyds TSB, this big bank, and it was very controversial at the time for a number of reasons.
One of the reasons I bring it up is kind of selfish, because having worked in M&A from the investment banking side, the details on the ground of what an acquisition or a merger looks like, were something that I actually never really - I never put on the hard hat, as it were.
This was a very important merger, and I think we often hear about things like Amazon just bought Whole Foods, and stuff like that. But, what was that like, working on a team, trying to bring together these two banks? Where people's life savings and the wider economy is at stake - what kind of work did you do, and what was the temperature like?
Rich: It was a unique program of work. I mean it was absolutely enormous, that program. My involvement on it was really tiny in the grand scheme of things, because it was such a huge program, and it affected so many people. But it was a perfect example of how testing can become very, very regimented. There was a big organisation who were controlling the testing activity that went on across that whole organisation. It became a case of a lot of reporting, a lot of providing metrics, a lot of - fulfilling a need for people to feel that testing was happening.
My involvement was with a particular part of the Lloyds Banking Group business. I was based in Bristol at the time. Lloyds had a big office there, and I was working as part of the commercial banking group there. We had a very focused responsibility on particular systems that affected certain customers, so we didn't get a lot of visibility of everything that was happening within that program.
But there was just this sense that there were hundreds, if not thousands of people involved in this. It was absolutely huge. I believe it was the biggest integration program that's been run. Certainly at the time, that's what people were saying. Whether that's still the case, I don't know. But it certainly affected many millions of customers. And so there was a big focus on, obviously, making sure that those customers were not adversely affected by what happened.
But there were also cultural things to bring into the mix. When you're bringing two big organisations together, it's not just a matter of technology, it's all the people involved. There's inevitably going to be - people's jobs are changing, people are going to lose jobs. There was a lot of implications of that program, and in many, many different ways. As a contractor working there, I was very mindful of all of those implications, not just the implications of the technology itself.
Len: I'm curious. You're originally from the UK, but now you're based in sunny Sydney, Australia. How did you - when and how did you make that change?
Rich: I've been in Sydney for about five years now. I'd actually been here for a short stint in Sydney about fourteen years ago, and when I was here, I did some work for a company who were then called Access Testing. I operated as a consultant for them for about six months. Now, when I finished my engagement with Lloyds that we just talked about, I did consider some different paths at that stage. I'd been involved in financial services and banking for quite a long time, and I wanted to try some different things. You mentioned games earlier. I even considered whether I could move into games testing, whether that was something where my experience could be valuable.
But another thing I really wanted to try my hand at was consulting. I'd had a very brief experience, but I felt that with the number of years I had in testing, I would like to try my hand at consulting in a bit more depth. So I contacted Access again, and through that, we came to an arrangement, and I moved the family over at the end of 2012. I was really excited to be not only starting a life in a new country, but starting a new chapter in my career.
It turned out to be probably the best career move I made. It was a great experience to work for a consulting organisation, and a company that are very, very innovative and very willing to try new things, but also to work in a different country, and to experience a different market. I often say to people here in Australia that I don't think they realise quite how pioneering they can be. It's a young country, and it's a place where people are willing to try new things. It's a cultural melting pot, Sydney. There's lots of different people from different countries coming together. But just in a business sense, people will try new things. They're not frightened to try new things. And that for me was very refreshing. It's been a great experience.
I don't work for Access anymore. I stayed with Access, who now are called Access HQ. The HQ stands for "human quality," which gives you a little indication as to how the book came about as well. We talked about quality from a human perspective a great deal, at that company. A lot of our services were tailored to trying to provide quality for humans. So it was a great experience for me. I have moved on, but I've taken those lessons and that philosophy on with me in my career.
Len: I've got a bunch of questions to ask you about that. Before moving on though, I wanted to ask you what was - I mean, spiders aside - what was the biggest adjustment that you found you had to make moving to Australia, or to Sydney specifically? It's a big country.
Rich: Yes it is. Culturally it's not hugely dissimilar from the UK. There's a lot of common ground, and from that perspective, it wasn't that difficult to make the adjustment.
I guess the biggest thing was just on a personal level. My family had two young children - my son was actually only three months old when we moved across. So it was pretty challenging from that perspective, and settling the family in. Just setting up home and adjusting to the way of life, was quite challenging. Interestingly, I suppose, fitting in to the new job was probably one of the easier parts of it. I certainly found that people were exceptionally friendly and helpful in all ways in Australia, and that really made it a lot easier.
I think it's a wonderful thing to do. I think if anybody has the opportunity to work in a different country, it's a great opportunity to take. I think you learn a lot about yourself, and you learn a lot about other people by operating in different countries.
Len: You just reminded me, with both Australia and moving to different countries - I've interviewed a few testers for this podcast who've published books on Leanpub. Alan Richardson comes to mind, also David Greenlees, who moved from Australia to New York City.
Is there's something that sets you apart - or is there any particular kind of preoccupation you have with respect to testing, that would be more unique to you perhaps than to other people? Is there any particular hobby-horse that you talk about when you're talking with other testers about testing?
Rich: The people you've mentioned there would probably be quite consistent with this. But certainly their more context-driven, their more exploratory methods of testing, is something that I'm certainly aligned with. I would never say that there's anything that's kind of unique about my philosophy. But I do think, going back to the start of our conversation, that that focus on the human impact of technology is something that perhaps gets lost sometimes, and something that I really am a strong advocate of.
I have a lot of interest in the world of usability, and of customer experience, and also human-centred design. Those are subjects that I've become very interested in. I see a lot of parallels with what we do as testers. I see that we can learn things from understanding those subjects. I think if you delved into conversations about testing over the last ten years, you'd probably find that many of those conversations revolved around the subject of automation, around the subject of testers developing their skills with coding and with automation.
I totally understand that. It's something that I support, and I believe that it's important for people to develop those kinds of skills.
However, I also think it's equally important that we focus on the human aspects, and we keep in mind that what we're doing is we are providing software and technology that is intended to benefit people. I emphasize this is my discussions around testing.
I guess we'll move onto the book. One of the things that I've introduced in there is this model of three dimensions of quality. They're intended to be quality aspects that are considered from the point of view of a customer, from the person who's using the software. Most of the discussions that we have around quality tend to be quite technical as well. If I had to pick out one thing that maybe is slightly different in my philosophy, maybe that's it?
Len: I have just one more question before we move onto books specifically.
A lot of people who work in say the startup or tech sector, like I do, often the entire company can be a small team, without necessarily the resources to hire a dedicated tester or a consultant or something like that. And so you end up - I like to use the word "cowboy" when I'm referring to kind of randomly just attacking things - and I've done, working for Leanpub, a lot of testing as a non-technical person, and certainly not trained as a tester. I've always approached it to be as creative as I can, to try to understand everything that can be broken, and then try to break it in as many ways as I can.
If you were to give advice, say to someone who's young, just starting out in a start-up and they need to test a product - what's the main advice you would give them for what to do? That could be a book to read, it could be a couple of techniques.
Rich: There's certainly some fantastic material out there. One of the best things that people starting out in testing can do is to try and tap into the testing community that exists on Twitter and the testing bloggers that are out there. There really are some fantastic people who are willing to share their experience and their knowledge.
This is a community that I probably only really tapped into over the last three or four years, but I have learned an incredible amount. It's been a real revelation to me to read people's stories and thoughts on things. That word "learning" is crucial. Testing and learning are absolutely linked - not only the idea of learning new things about how you test to improve your career, but as you are testing, you are learning. I think it's crucial that testers have an interest in learning.
If I had to pick out some specific recommendations for people, certainly I would say, anything by Gerald Weinberg. But specifically, the book, Perfect Software: And Other Illusions about Testing , which for me is the single best book about testing. It really does challenge a lot of the perceptions that exist about testing, and offer some really practical advice as well.
There's a whole lot of other people I could recommend. I could list off any number of names for you. But really if you tap into that testing community, that's a great place to start. I should probably actually mention the Ministry of Testing as well, who provide a huge number of resources and will introduce testers to lots of the key people that they should probably follow and pay attention to.
Len: Moving onto another resource that I would personally, definitely recommend. Your book, Changing Times, which, I was mentioning to you before the interview, I really like in a number of ways. Before I go myself into a little bit of detail about the book and how it's structured, I was wondering if you could explain a little bit about what the book is about, and who it's meant for.
Rich: I recognise that the primary audience for this book is probably going to be people who work in software development. However, I really didn't want to limit the audience to that group of people. I tried to write the book in a way that made it accessible to anybody - anybody who has an interest in technology and how it affects our lives, I hope will get something from the book. But for people who do work in software development, I hope it promotes thinking about the human aspect of technology. And I hope it maybe presents a different perspective on some of the trends and some of the things that are happening in software development now.
I'll cover, for example, Lean and Agile development. There's a package in there about continuous deployment. There's various elements about some of the things that are going on in software development that I hope will give people a different way of looking at things.
I did want to target a wide group of people with the book. But I also wanted to maybe do something different in the way it's structured.
As you said at the start, many of the books I read, and the books I really love, are very focused on the methods and maybe the theory of what we do. I wanted to marry up a fictional and a non-fictional element. It's almost like writing two books, and bringing them together to create something new.
Len: That's one of the things I really enjoyed about the book. In particular, the structure is, throughout the book, you're chapter-by-chapter telling the story of a day in the life of a journalist, from when she wakes up to later in her day. The chapter will describe a portion of this journalist’s day, what they do, and the many different ways in which they interact with technology, and in a way, how the technology interacts with them.
I have to say, right from the beginning, the lucidity and detail of the descriptions of this person's activity struck me. I'd never seen anyone describe so accurately - put a mirror up to my own existence in some ways. There's this great description of how the first thing she does i,s she hears the tone of her phone, because that's what she uses for her alarm. And then she opens it up, and inevitably she ends up sucked into social media, or thinking about getting sucked into social media, "Are there going to be people attacking me?" and the routine of having to block or report people.
Things like that, and the way you tie that into the fact that as a female journalist, she might be subject to particular kinds of interactions on social media that not necessarily everybody else would. It was just fascinating. Not just because of the structure of story about a person, and then the description of what their interaction with technology was like, but also holding up this mirror to our lives, in a way that I've never read. I mean, people talk about it all the time, people write about it all the time, but where the focus is on the details of that interaction, that we're doing all day long, I thought was really brilliant.
One idea in particular that seemed to come up a few times, that I wanted to ask you about, was temperature changes. From my description, people were probably thinking, "Oh it's all about screens and stuff like that." But one thing that you describe multiple times, is the experience of going from - you wake up in an air-conditioned space, and then you walk out and you're in the heat, and the impact that has on you. Or you go from the heat, into an air-conditioned space. Was that deliberate that you brought that up repetitively? Was there something you were trying to get at there?
Rich: It wasn'tan allegory for anything. You mentioned David Greenlees earlier. I read an article David wrote a few years back about usability, and the effect of people's moods as they enter into usability testing sessions. I think this is a really important point, that we often think about personas, and we often think about emotional responses to technology. But we don't always think about how people are feeling as they enter into that relationship.
So in the story, as Kim moves into these air-conditioned environments, and out into the heat, it all plays a part in setting her mood, and it plays a part in how she feels. And that in turn affects then her interactions with technology. She feels more frustrated in situations where she's maybe a bit hot and flustered, or she's rushing for a bus or whatever it may be. And we - sometimes lose sight of that.
As humans, all of these things affect our lives. They therefore affect our perception of the products that we use, or the technology that we use. It's a very complex relationship.
I really wanted to try and get that fact across. The words you use are very kind, and the things you said - about holding a mirror up to our lives. That was something I really wanted to try and do. I wanted people to feel a bond with Kim, that they could relate to her. Because it was similar to her life.
Certainly, some of the examples come from my own life. I know I'm not unique in picking up my phone as soon as I wake up in the morning, and scrolling through social media. I recognise that that's not a healthy thing to do. So I talk about that in the book. But it's important that we recognise the social changes that are happening as a result of the technology that we use. It all plays a part in that complex relationship we have.
Len: Speaking of mood in that concept relationship. This is probably going to be a long question. I'll try to keep it as short as I can.
You have a line which gets to the heart of one of my own product design hobby-horses, where you say, "A product which is regularly enhanced will inevitably lose some of its familiarity." One thing that's true of every "enhancement" is that it's a change, aAnd whether the change is positive or negative, the user in the first place relates to it as, "Oh something's changed."
And they have to adapt to every change that's made. So whether it's positive or not, the first experience is always, "Ah, it's different now." One of the only semi tongue-in-cheek jokes I have is: You often end up, when you're interacting with products, like digital products, software products - you can feel like you're in a real life adventure game, where you have to solve some arbitrary puzzle every time you try to do something in your environment. You know, like old games like King's Quest, or something like that. It's like - how do you open the door? Well solve this crazy, arbitrary puzzle.
My non-technical brother has an analogy with doorknobs. I say he's non-technical, because he complains about how technical people sometimes enjoy the challenge, and forget what it's like for just a normal person trying to use it as a piece of equipment. He says, "Imagine every time you went back to your home, the way the door knob worked had changed?"
You'd start to be scared to try to open a door, and you'd be apprehensive even approaching it, even if you knew it would be a simple puzzle. It's like, "Really, like this is my house, and I've got to figure out something new?"
One of the things I enjoyed about your book was the dry humour. You have an example of this, where you say, "The website was apparently created with a secondary purpose as a kind of psychological test."
I wanted to ask you - from the perspective of people who are creating products and designers and things like that - they often feel that their job is to keep putting out new designs. Because that's what they're there for, to keep putting out new features, keep putting out new enhancements.
Do you have any advice to people like that, how they can avoid falling into that trap? Because you often don't know that people stop using your product, because you made an improvement. Or because you make improvements too often, and now they just relate to it as this thing that can't be depended on. How can people avoid that?
Rich: I think probably one of the most important things is, just bear in mind what you said at the start there - that familiarity with a product is important to some people.
People don't necessarily want change, they may be comfortable with what they have. One of the other things I talk about is how- the very nature of what a product is has changed.
We used to go and buy a car, and a car would have a list of features. You would know that when you entered into that arrangement - you bought that car, you would be buying it, and it'd probably last you four or five years. It wouldn't substantially change. You may change elements of it, you may change the tires. But the car was still the car.
Now with what's happening with motor vehicles, you get updates. Your product changes over time. You don't necessarily end up with the product that you started out with. For some people, that's exciting. For other people, they're not so comfortable with that.
From a designer’s point of view - and look, I'm not a designer and I'd hesitate to offer too much advice to designers - but I'd certainly say, consider your customers and consider the many different factors that go into their relationship with the product. If they are familiar with something, if they are comfortable with something, they may not want it to change.
I realised that, as I was writing about continuous deployment in the book, I was swimming against the tide a little bit. Maybe people who are advocates and evangelists for continuous deployment may not agree with what I was saying. But the trend is very much for rapid, frequent delivery of change at the moment. And whilst I understand that, and I understand the competitive advantages, and I understand the benefits of being able to respond to customers quickly - those are well understood, but there's another side to this, which is thinking about the impact on the customer. Thinking about the person who is actually using the product, and what it means for them. It doesn't always follow that frequent, rapid change is what a customer will want. It's worth thinking about that, depending on the context of the product and what your customers do with it.
Len: I was going to say - especially depending on the context of the product. For example, we spoke earlier about you working on banking processes. I believe you work for a large insurance company now. And you reminded me, I was just paying royalties to our authors today. We pay at the beginning of every month. We've paid out millions of dollars to Leanpub authors. And of course, I use a payment service - which I won't name, because I love them in many ways - but in their design, they've started doing things that might be totally appropriate in another type of company where continuous deployment and things like delight and things like that might be what's most important to people, to keeping them using it.
What they've started doing is these crazy spinners and lightboxes and things to interact with. In particular, when you go to pay, they randomly show you a set of circle faces and account names, which is supposed to make you pleased or something. But the thing is that, from the perspective of someone making payments, I don't care what the circle face is. I certainly don't want to be shown anything random. And I don't want to be shown an account name either. Because what I'm doing is, I'm sending money to an email address.
Rich: You just want a payment.
Len: You just want to make the payment. But anybody can upload any image they want to their account, and anybody can enter any name they want - any first name, last name into their account. I cannot know who that is for sure, if I'm only seeing that information. Now if I'm on social media or something like that, if I'm on Facebook, if you make a mistake or someone messes with you a little bit, maybe it's not the biggest thing in the world. But if over time, sending out millions of dollars in payments
I guess what I'm trying to say is, nobody who'd ever had the responsibility of doing that, and nobody who ever feared sending $50 to the wrong person, because then they don't have another $50, and Grandma can't come visit for Christmas, because she can't get a bus ticket now - nobody who ever approached things from that perspective would ever have designed a payment system the way this one has been designed.
I was wondering what you think people who, say, are sitting on top of a product can do to help their designers be more empathetic with respect to the specific needs of the product that they have - rather than what the latest design fad or convention might be for impressing your fellow designers?
Rich: The example you gave is a great one. One of my colleagues at the company where I now work - which, as you say, is a big insurance company - I've heard them saying, "People don't want to be entertained when they're signing up for an insurance policy."
Rich: They just want to get it done. It's a different kind of product. Depending on the context, having something which is enjoyable to use may be very important. But it's not always important. Sometimes it just has to be useful. It just has to be able to do the thing that it's intended to do.
In terms of understanding what matters to the people who are going to use a product, the simplest thing is to talk to people, to spend time with them, to try and understand the way they use it.
One of the great things that I've seen at this place where I'm now working is that developers and technical people will actually go and sit with colleagues who operate in customer contact centres. They'll actually sit with them and see how they use the applications they work on. They will look at the practical things they do to get to work around some of the problems that occur. And then developers can take that back and can adjust the way they work. It really makes a difference to that relationship between the developer, and in this sense the colleague or the customer who is using the product.
Having that deep understanding of the way people actually use things is crucial. And it's not easy. Empathy is a word is used a lot in product development. I obviously have a whole section of the book about empathy. It's something that I think is absolutely crucial.
But it's not easy. You can't just switch it on. You have to really spend time with people and understand the way people do things to develop that empathy for them. Only then can you apply that thinking to the work that you do in developing technology.
Len: One of the things you write most about in your book is the stuff that we know we're interacting with. But you also write, "Some of the technology which affects us is visible to us. Yet more is hidden from view," and you talk about how this hidden technology is used to influence us. This is where things about empathy and things like that get really subtle.
Let's say you're making a product or testing a product that the person might not even know is there in their life. I was wondering if you could talk a little bit about what technology you're getting at when you talk about what's hidden from our day-to-day ordinary, literal view of things?
Rich: Specifically there, I guess I was referring to the data that we provide, whether we know it or not - the way that that data is used. There's an example I give in the book of re-targeting in advertising, when you go on to a website, and you buy a television, and then for the next month you see adverts for televisions. Which seems a little strange, because you've already purchased a television, so why do you need another one?
But it was really about - we're very aware of the technology that's presented in front of us - the devices that we use, the websites that we use. But there's a whole lot that sits behind that, the data that underpins it. It's important that people are aware of that, and they're aware of the fact that they are providing companies with something when they use a product.
I think when I describe the concept of a customer, I talk about how, even if a financial transaction hasn't taken place, you are a customer. If you use Google or any of the other major websites, you are a customer, because you are giving them something. You're giving them data, and you're giving them your time. You're giving them traffic. These are all things that are valuable to them. They can make money from this. So you are a customer, and it's important that people are mindful of that. Because technology is so intertwined with our lives now, that understanding the extent to which that occurs is probably an important thing to for us all.
Len: It's maybe a slight digression, but I'd like to ask you, what is your opinion about that broadly? I know one often hears, maybe from the EU or something like that, about governmental organisations potentially creating regulation that means users whose data is being used in these ways you're describing, should be compensated somehow?
Would it be enough if the company simply were more explicit with you about what they're doing, and what they're using it for? Do you think that there should in the future be some compensation for the user? If Google is watching everything I do, and then selling that information on to advertisers essentially, should I get paid?
Rich: I think probably more than the financial aspect of it - I think it's more a question of control. I think increasingly, people will want to have some measure of control over what data is taken from them, what information is taken from them, and how it is used.
That's not going to be an easy thing to overcome. People don't necessarily want to spend time reading through terms and conditions and familiarising themselves with how things are used. But I think there's probably a balance that needs to be addressed in terms of who owns that information.
I, as an individual, would like to feel that I have control over how much information I provide, and how companies use it. How we do that? I don't know. But I think that's probably the more important discussion than whether people should necessarily be financially rewarded for that data. Some people may want to be, some people may be very happy to pass over large amounts of information. And they may want some financial return for it. Other people may say quite the opposite view, that they'd much rather keep control of that information themselves.
I do think it's a question that not just governments, but the big tech companies need to ask. How do they manage that relationship with their customers in a meaningful and fair way, that allows customers to control things?
Len: As you point out multiple times in your book, and this has deep meaning for how one creates and designs products - but everybody's different, even individually over time. As you say, as their mood changes, and as they change.
O interesting thing I've encountered around data is, Leanpub sells books, and we deal with authors all the time, and readers, and ne of the debates, as you know, is Amazon versus the indie bookstores. I won't go into specifics, but there is this collection of bookstore owners and advocates in a city in the United States where Amazon was going to be opening a warehouse or something like that, and they issued a press release, where they said, "Amazon is just gathering all of your information. It's just gathering all your information. Do you really want that? What you really need is us to personally know you, and know everything about you - enough about you, that we know better than you what you need to read next."
They talked about both an algorithm - and, meaning "algorithm", a "logarithm" which I thought was hilarious - but they said, "Amazon may have the logarith, but we've got the personal touch." It was just really curious. There's a certain type of person who gets mad at - what is it? The French have some acronym for like Google, Amazon, Facebook, Microsoft. "Oh no, that's terrible. Data about me exists on these computers out there and is being collected by computers. But the local guy actually knowing everything about me - oh, I'm totally fine with that. There's nothing sinister going on there."
I just bring up this example, partly Because it's funny, but partly because it goes to show that when you're creating technology and when you're interacting with people, it's not just that they will differ from each other, it's that they may even hold internally contradictory positions. The challenges of addressing this when you're making a product that's meant for a wide consumption are vast and not necessarily reconcilable.
Rich: That's a really important point. I mean I guess I only touched on it really around trade-offs, and the fact that, to make something more usable, you may need to compromise on security, for example. To make something more personalised, you may have to take more data from people. There are trade-offs here. There's a responsibility on each of us as individuals as well, to think about what we really want.
It's not necessarily a case of just blaming the companies and saying that they're taking things from us. We have a responsibility to ourselves as well. We have to be realistic about what the technology can and cannot do. There are trade-offs that the companies have to manage, and there are trade-offs that we have to be mindful of as individuals as well.
Len: Speaking of being mindful - that reminds me of a distinction you draw in your book between this concept of build quality in, and what I think you advocate, which is, think quality in. I'm guessing you're being a little bit provocative, perhaps, with that distinction? I was wondering if you could talk a little bit about that?
Rich: It was a little bit provocative. I hear the term "build quality in" a lot. There's a couple of problems that I have with that term.
The first is that, it implies that quality is a ingredient, it's a tangible thing that can be stirred into the pot, and mixed in. And suddenly if you add quality in at the right time, you're going to have a quality product. We know it just doesn't work like that. It's a a strange way to look at things.
And the other thing is the word, "build." Rightly or wrongly, I think people tend to associate that with developers, with people writing the code. It's almost like the burden for quality, it's an attempt to shift it from testing, which is obviously not the right place to think about quality, to people who are writing the code. What I'm saying is, that's not enough. We have to think about quality at every stage. Anybody who is involved in the idea behind the product, the design of the product, the way it is built, the way it's implemented, the way it's supported, the way it's maintained. Quality is something that is a responsibility of all of us.
And I know that when people first talked about build quality in, that's really the point they were trying to get across - that it is everybody's responsibility, and I completely support that. I just think that the term itself, "build quality in," has maybe been slightly misinterpreted. I'm just putting my own spin on it, saying that we ought to think about it at every stage.
Len: One of the great points you made when talking about quality in your book was about the fact that people - especially perhaps people of a certain type, or at a certain type of organisation - often have a tendency to try to quantify quality. You have this great pun, which may not be original to you, but I don't know if I have come across it before, where people take refuge in numbers - not in groups of people, which is the way it's meant, but in actual numbers.
You have this great joke too, I think it's something like: imagine you're at a construction site and the foreman says, "Bring me some cement. Oh and by the way, bring me a bag of quality as well please."
I was wondering if you could talk a little bit about that. Why can't you quantify quality?
Rich: This is a very big subject. It's something that comes up for discussion a lot amongst the testing community, because quite often we will be asked to do exactly that as testers. And I will hold my hand up and say - I've tried to do it, over the years, I've produced horrible graphs and charts and Excel spreadsheets with numbers in them, that at the time I thought were good ways of measuring quality.
I guess what I've come to realise is that you cannot put a simple numeric measure on quality. There isn't a single unit you can apply that will tell you whether quality exists in your product or in the relationship between the product and person. Because it is so subjective, there's a number of different things you need to think about. I'm not discounting metrics completely, I'm not saying that we should ignore them, because I do think that there are patterns that metrics can sometimes display that give us a clue to where there might be problems. But to me, they tend to be more related to problems with the process, rather than the quality of something.
I hesitate to use the word "defect." I don't really like the word a lot. But when we have large numbers of defects emerging during development, it may be something to do with the way that people have been asked to work. It may be people are being put under pressure. It may be a sign that communication isn't working well, and there's misinterpretation of what the product is supposed to do. It doesn't necessarily tell us anything about quality, because what might be a defect to one person, may not be to somebody else. It is very subjective.
I think it's important that the emotional response to products is, we pay attention to that as much as we do to numbers about things like how many test cases have been run and how many defects have been raised. Those things don't necessarily tell us whether we have what we wanted, or whether our customers will get what they wanted.
Len: As you say, it's a really big topic, and very broad in what it touches on. But one of the things I've noticed is that often - to invert the normal charge that goes along with it - often people who demand the data and demand the numbers are actually being very lazy intellectually, and the reason they get away with it is because "the numbers" is usually associated with a macho, hard-ass, objective approach to things.
And then when someone comes along and says, "No, it's actually subjective," they'll represent that person as being insufficiently rigorous or something like that.
But what you end up with then - because there's this top down, cultural macho pressure to have numbers - uou end up engaging in nonsense, magical thinking, like, "The publishing industry will grow by 3.25% in the next five years."
Nonsense. That's just bullshit. You can't predict who's going to win the Superbowl next year, but you can tell me that an entire global industry is going to grow by like - to two percentage points at the end of three years from now?
But somehow, the introduction of numbers into certain types of practices, brings with it this aura of an objectivity and a predictability that doesn't really exist, but people find comforting. Especially people who might be, say, higher up than you, who have to report to someone higher up to them.
If they just go, "Oh well, it's all getting a sense of things." They'll be like, "Well that's not a good basis fo - even if that were true, that's not a good basis for discussion, give me some numbers."
Rich: Yes. It's easy to distill numbers. It's easy for managers to extract what they want from numbers, and to distill them into another message, which then goes to another layer of people and so on and so on. And as you do that, you move further and further away from the reality. The best reporting on testing is when people talk about it, when they have conversations about what they've observed, and what this has told them about the product, and what this may mean for customers who are going to use the product, and what could be done to address it?
They're conversations, they're stories. But those kind of things are not easy to summarise and to pass up a reporting chain, which is why people do - there is safety in numbers, because it's something that everybody understands. It's black and white, it's tangible. And it's a very, very hard conversation.
I know a lot of testers struggle with this, about when you have that macho environment where managers are pushing for numbers. It's not easy to say, "No." It's not easy to push back and say, "Look, those numbers don't actually give you what you want to know. Let me talk to you about it."
It's something of a skill which I guess testers probably need to develop over time. They need to build up good relationships with the people who are asking for numbers. They need to understand why those people want those numbers. And they don't need to think about, "Well what can I give them instead that will maybe give them something more meaningful?" It's possibly slightly underrated, and maybe not thought about enough as part of the testing role. How do we give information that is meaningful and useful to people?
Len: My last question about the subject of your book is that - you mentioned this earlier - you talk about three dimensions that affect our perception of quality. That if you are talking perhaps in a non-quantitative way about a product, you can reference its desirability, its dependability, and its durability. Could you talk a little bit about those three dimensions and what you mean by each of them. So let's start with - what's desirability?
Rich: I really talk about a product being desirable from the point of view of how the person feels when they're using it. This comes back to one of the main things in the book - this subject of a relationship between a person and a product, which is something that -
I actually read, Zen and the Art of Motorcycle Maintenance quite recently. That relationship is discussed [there.
I put a quote in the book from Michael Bolton, which he talked about in a blog post. Those three dimensions play into that idea of a relationship. We know what is desirable to us in a relationship with a person. I don't necessarily use the word "desirable" to mean attractive. That's part of it. But it's really about what we want. What we need from that relationship. So there's a number of different factors that are covered. I won't go into all the different quality aspects within each of the dimensions, but I've tried to pull together a number of human-focused words that relate to each of the dimensions. And with "desirable," it's the factors which make products something that we want to use. Something we want to own. Something we want to have.
Moving onto the others, "dependability" is really about - if something's dependable, it's all about the trust that we have between ourselves and the product. The factors that make us trust something. Something we can rely on. It's, again, a number of different things that play into that. But it's a very important part of a relationship, that we have trust.
Finally, the last one is "durable." And durable is about how enduring something is. I know that durable can also mean robustness. How tough something is. And again, that could be part of it for a particular product. It may need to be robust.
But really I'm using the word "durable" to describe how long-lasting a relationship is. I give an example in the book of, Kim has a digital voice recorder that she uses as a journalist. It's something she's comfortable with. She doesn't feel the need to replace it, even though some of her colleagues tease her about it. They've all got more modern devices than she has. She doesn't care, because she's happy with what she's got. And therefore she has a long-lasting relationship with that particular product.
Obviously there's a bit of a play going on with the fact that it's three Ds and it's three dimensions, but I think those three factors, which I'm not by any way saying that they should be treated as a standard - if you have these three things, you have quality. I'm just encouraging people to think about those three dimensions as different ways to consider quality from a human perspective.
Len: Speaking on the subject of products and quality, your book itself is a product. And one, I would say, of high quality.
One thing I noticed was that you used Leanpub's "Bring Your Own B"ook feature to publish to our book store. This lets authors create their own ebook files with any tools they like, rather than Leanpub's workflow, and then upload them for sale on our store. I was just wondering what tools you used to create your book? For anyone out there who's interested in self-publishing?
Rich: I was very fortunate with the publishing. My sister actually runs a publishing house in the UK, called Haven Publishing, and she does some proofreading and editing services as well. So I really drew on her knowledge. She's actually written three books herself, three novels. She gave me some good pointers about writing a book. The process itself for me was slightly strange.
I was just snatching time to write when I could. Working full time and having a young family, it's difficult to find time to write. So I actually was writing on my iPad a lot of the time. I had Microsoft Office on my iPad. I was writing on the bus going to work. Then in the evenings, when I had some time I would write as well. Weekends were a good time to do some writing. But I really had to just be able to switch it on and off. And so it's really important that I had a map of what the structure of the book would be.
So I used mind map to build up the structure of how I wanted the book to work. When I'd got most of the words down, which was really many months before the book was published, it then went into what I found was the most frustrating and difficult period, which was reviewing and reworking it. I did find that incredibly difficult. I was very lucky to have some fantastic reviewers from the testing community, who I'd come across on Twitter, who gave me some fantastic feedback, and I was very, very grateful to them.
But just the process of waiting for comments to come back, and finding that sometimes the comments contradicted each other, sometimes I didn't agree with them - I found it really difficult. I found that I got sucked into this world of analysing individual words in the book. "Was that exactly the word I meant, and did I want to change the wording slightly?"
You can get really bogged down in that. You could get to a point where you never released a book, because you're so intent on getting it perfect. And obviously, it's never going to be perfect. You have to accept, you have to compromise. You have to make little changes that perhaps you wouldn't [have done in the first place].
But once that was done, I passed it across to my sister, who did the formal editing of the book. She did a fantastic job on it for me.
I also had illustrations in the book. One of the things I really love about the book is the illustrations, which were done by a lady called Catherine Clarke. I gave her an idea of what was happening in the chapters of the book, and Catherine pulled together the illustrations. There was a lot of to and fro between myself and Catherine on what the illustration should look like.
Len: How did you find your illustrator?
Rich: Catherine's a friend of my sister. She's done a lot of the illustration and covers for the books which Haaven Publishing produce. I was really delighted with those illustrations. They're absolutely fantastic. They really bring the characters to life. And I really wanted that - I had in mind a book I used to read when I was a kid, Three Men in a Boat by Jerome K. Jerome, which was written - I think it was 1890's that book was written. But each of the chapters has a little black and white illustration at the start, and I wanted something similar. I think that Catherinedid a great job in putting those together.
But as the the form of the book took shape, it did become quite a laborious process. you get to a stage of, right away, all you want to do is publish the book. You've done what you feel is the hard bit, which is writing the words. You just want to get the book out there. So it can be quite painful waiting for those final steps to occur.
Len: One thing - in a way, I'm not surprised to hear that you went through agony because, and I guess this is kudos to you and to your sister and all the people who gave you feedback, but I found one typo in the book. It was almost like, as I turned page after page after page, "How was this done?" Because it's hard to write a book with, and publish a book, no matter how many people are involved, and no matter how professional the copy editors are and how big name the publisher is - to achieve what you guys have achieved is pretty remarkable in my experience. So I want to say that even though you may have gone through some agony , from a reader’s perspective, we're all grateful.
Rich: That's very kind. I feel like - even though you're saying there's only one typo, now I've got that feeling of disappointment: "Oh no, a typo."
It's interesting, because part of the subject of the book is about product development. And it does give that sense of what it's like to release a product, and wanting to get it right, and wanting to provide something which, in this case, readers will enjoy. It's really tough, and you do have to get the balance between trying to perfect something, and something that's good enough.
I don't like that term, "Good enough." I like to try and get things exactly how I want them. But you can't always do it. It really does take a team of people to work on a book. Everybody says this, I know every author says this in their notes at the start, but it's not just down to the author, there are so many people involved in producing a book. So many people that you feel grateful to, and that you want to thank, and you want to acknowledge for everything they've done in helping you to think about the subject, and to go through the process of writing the book.
Len: One of the fun things about this job is seeing the different approaches that so many authors take - the canonical Leanpub author - everybody has to fight that battle. When am I ready to release? And with Leanpub, because books can be published in progress, you perhaps see people who have a wider spectrum of choices than they can make then in more conventional forms of publishing.
But the one key factor that unites them all is, it takes a lot of people to make a really good book, usually, and one of the great things about getting a team together, is that, although you as the creator of it - and I very much sympathise with this. "Oh no, a typo" - the person who found it, though: they feel good, because they helped you out. And that can be someone you're paying as a copy editor. That can be a colleague that's reading your book. Or it can even be a customer who emails you, or something like that, and says, "Hey, I found this on this page, can you fix that?" One of the nearly universal things is, it takes a lot of people to really make something perfect in the end.
One question I always like to ask people as I wrap up an interview is: if there's anything about Leanpub that we could build for you, that you can think of, what would that be? Or if there was anything we could fix for you, what would you like us to fix?
Rich: I was thinking about Leanpub before we started talking, and one of the subjects that does come up inthe book is that, a product is much more than the code and the technology that people use. A big part of it is the support around the technology. You can use a terrible product, but if the support that is around it can retrieve the situation, you come away with a warm feeling. And one thing I must say about Leanpub is, the support has been fantastic.
I've actually been really impressed and blown away by how quickly you have responded to questions that I've posed. There's been a few things where I've emailed questions through, and you respond so quickly and so thoroughly, and with so much care - that's a fantastic thing. That goes above and beyond the platform, which is excellent as well.
I've really found the whole process of understanding sales and how things work really simple on the platform. Obviously I didn't get to experience the process of actually writing the book through Leanpub. But as somebody who's effectively published, and who is selling the book through Leanpub - it is a wonderful experience. I can't think of anything that I would say would be a major improvement on it. Itt's been great.
Len: Thanks very much for all of that. I will cheerfully, on behalf of the team, accept the compliment and the feedback. We really appreciate that. It's been a lot of years of interacting with authors and readers to get it to the point where people can say things like that about it, and we always really appreciate hearing that from authors.
Thanks very much Rich for taking the time on your Saturday morning to talk to me. It's Friday evening where I am, Saturday morning where you are. I had a really great time. And I wanted to thank you very much for being on the Frontmatter Podcast, and for being a Leanpub author.
Rich: Thank you, it's been a real pleasure to talk to you. Really enjoyed it, thank you.