Category: Books

June – Toread

Toread

At the intersection of software, technology and people 

What is this?

Things I’ve been reading this week that I’ve found interesting or intriguing. Sharing because I thought you might like them too. Most of the links will revolve at the intersection between software, technology and people – with the occasional testing slant. I aim to update them weekly, with some commentary on my thoughts and findings. Feedback always welcome 😁

29th June

🎓 Why Your Organization Isn’t Learning All It Should In your every day work do you have time to look at the cause of small issues or do you work around them with hacks and fixes? Can you bring them up with other colleges or are they brushed off as trivial or worse are you labelled as a complainer? As detailed in How to learn from failure and Nobody ever gets credit for fixing problems that never happen it’s usually these small preventable problems that build up into big complex problems so having time to get at the 2nd order problems (root causes) is really important. Also research suggests that once you start fixing these issues there is a re-enforcing effect that encourages others to raise problems but also start to address them too, slowly improving the whole system.

🖥  Brief history of Apples OSX If you primary work machine is a Mac then having a basic understanding of its history helps you understand why it works the way it does. If it’s not your main machine then this short history lesson can also help you understand what Apple did that was different to iOS and to some extent Windows. 

🔬 First and second order problem solving From the article: research on problem solving makes a distinction between fixing problems (first-order solutions) and diagnosing and altering root causes to prevent recurrence (second-order solutions).First-order problem solving allows work to continue but does nothing to prevent a similar problem from occurring. Workers exhibit first-order problem solving when they do not expend any more energy on a problem after obtaining the missing input needed to complete a task.Second-order problem solving, in contrast, investigates and seeks to change underlying causes of a problem.

👩‍🏫 XConf Online Usually a free to attend conference held by ThoughtWorks at different locations throughout Europe with one being in Manchester. But COVID means it’s all online so anyone from anywhere can attend this year. It’s usually a multi track conference but this time they’ve just gone with one track with all of the talks coming from ThoughtWorks employees.  

In previous years they’ve never really had any talks on testing but this year they had three covering what a unit is for a mainframe system, testing things in production and mutation testing. The interesting thing was none of these talks where given by testers but developers. Is this a sign of things to come 🤔?

All talks should hopefully be made available soon so I’d highly recommend checking them out. Personally I got a lot out of the Redefining the unit and Your test coverage is a lie (mutation testing) talks for which you can find summaries in my notes.

22nd June

🗞 75 years of US advertising – This will help you create a deeper understanding of the advertising market and how the trends in online businesses and consumer behaviour (think end users) is sifting power from the traditional advertising conglomerates (print/TV/radio) to the online ones (Google, Facebook, Amazon etc). It’s not a simple lift and shift but a decline in business that did mass marketing to business that need targeted advertising. 

🕵️‍♀️ Snopes on white privilege in America – Snopes was something I used a lot when I was in my late teens/twenties to disprove things that used to be flying about on the Wild West of the early internet days. This time they pull part an argument that white privilege doesn’t exist in America. This is a long but worth while read on what white privilege is and how its affected black Americans lives.    

🍏 Apple begins to enforce in-app purchases (IAP) of *any* good – Why should testers care? Understanding the what of this is useful in knowing how it could affect the apps you work on and other apps in the market.

🤖 Ironies of automation The two ironies 

  1. Designers of automation believe that the manual operators are unreliable and sources of problems. Therefore believe that by automating the manual task remove the unreliability. The irony here is that the errors that the designer unintentionally creates in the automation are the major source of unreliability in the process 
  2. Designer who attempt to automate the manual operator away still leaves the manual operator in the process to handle the tasks that couldn’t be automated. The problem here is the tasks left for the manual operator can be quite arbitrary with little thought for how they will actually carry out the task resulting in a new set of issues. 

This is not to say that automation is bad but some of the intention (removing people) may not be for the right reasons (improving the process). I believe if the focus was to improve the process then the risk from the two ironies could be greatly reduced. One of the best ways to achieve this is to actually include the manual operator as part of the improvement process. Essentially have a user centric approach to improving systems.

15th June

🎓 SQ3R learning technique 30s reading time
Not come across this one before but could be useful for helping you recall things you’ve read . I particularly liked attaching meaning to the content and looking at it from different viewpoints .Personally I’ve found I’ve done this unknowingly with some things and it really does help with recall. Plus trying to re-call it again at a later date and applying that knowledge to different situations has helped further embed that information.

🗣 Asking Powerful questions 1 min reading time
The Powerful questions pyramid could be a helpful tool for asking more open questions that get people thinking.

📑 Making job descriptions more accessible 3 mins reading time
Stop reusing job descriptions and start tailoring them to the candidates you want. We’re not doing ourselves any favours by sending out the same old thing every time.

5th June

📰 The Origin of Product Discovery or what is Product Discovery? … true collaborations between engineers, designers and product managers. Not a dictatorship run by a Product Manager.  But what does true collaboration in this context actually mean? Which leads me onto a scales of collaboration…

 ⚖️ Scales of collaboration While thinking about how people and teams collaborate it occurred to me that there must be scale from not at all to full collaboration.  Quick search returned something called the levels of collaboration. This could this be helpful for teams to 1] make them aware how well they are working together and 2] what would they need to improve to able to get better at it. Maybe we should stops saying we need to collaborate more and start saying what that actually means? Which leads me onto some advice…

☀️🧴It was that time of year again (🎂) so what better then some advice: Learn how to learn from those you disagree with, or even offend you. See if you can find the truth in what they believe taken from 68 bits of (someone else’s) unsolicited advice. Need some life advice then this list is a good place to start, there’s a video too. But I think I’ll always remember  Mary Schmich column, Advice, like youth, is probably wasted on the young better know as the lyrics to Baz Luhrmann song Everybody’s free (to wear sunscreen)

🤔 Long read of the week comes from Joep Schuurkes Nobody ever gets credit for fixing problems that never happen: Creating and sustaining process Improvement. The work harder and work smarter balancing loops in this model do a great job of explains what “work smarter, not harder” actually means. But the reinvestment reinforcing and shortcuts balancing loops really get at what goes wrong with most process improvements initiatives in software organisations: it’s difficult to attribute process improvements to improved performance the way you can with working harder. So we trap ourselves with working ever harder till one day you just can’t do it anymore 🤯

May – ToRead

Toread

At the intersection of software, technology and people 

What is this?

Things I’ve been reading this week that I’ve found interesting or intriguing. Sharing because I thought you might like them too. Most of the links will revolve at the intersection between software, technology and people – with the occasional testing slant. I aim to update them weekly, with some commentary on my thoughts and findings. Feedback always welcome 😄 

May Round Up

Three new posts this month with what is a quality culture within teams and what do people mean when they say they have confidence in test automation? I also attended Agile Manchester which had a lot of talks that related to testing and testers too.

I’ve been using Headway to get digest of books which has been pretty good for working out if it’s worth going all in on. I can recommend reading the The Coaching Habit and The five dysfunctions of a team but wasn’t so sure on Leaders Eat Last. Scroll down for my summaries of the books.

It turns out google do have testers, ThoughtWorks got a new technology Radar out which is always worth a look through, Spotify called them squads because it sounded cool and risque was all about pirates for 18th & 19th century merchants.

31st May

🕸 Technology Radar (PDF download) of the latest trends as seen by ThoughtWorks. Always worth a look through as they have the advantage of seeing what’s actually happening with tools, platforms, techniques and languages within the industry. Still recommending team use pipelines and infrastructure as code (worrying teams are not!). Simplest possible feature toggles which is exactly what it sounds like use if/then statements if you can get away with it. Some useful tools for ethical bias testing of ML algorithms too. Visual regression testing was another mention worth looking at for legacy systems but be careful of it turning into your only form of testing. It tells you nothing about behaviour change of the system unless that results in a UI change. 

📖 Thinking in Systems Quick primer from Headway on systems thinking but be warned this isn’t enough to get why it’s a useful way to look at things. So you’re better off reading the full book. Thinking in terms of systems might make it easier to understand the world a little better and maybe how you can tackle those big problems.  

25th May

📮New Post: Building a quality culture: Is it quality assurance or quality awareness? I’ve been thinking a lot about who does what in a teams lately and especially about automation and exploratory testing. That’s when the two different meanings of QA occurred to me again.

🗣 OnlineTestConf 2020: Testing Stories in Modern Times by Alan Page. The future of testing looks to be less about traditional testers running testing (even exploratory) and more coaching teams on what quality means and how they build it in. You might be able to sign-up still and get the download.

📰 Not even wrong: ways to predict tech “That is not only not right; it is not even wrong” – Wolfgang Pauli. Sometimes with testing and especially exploratory testing it can look like we’re just trying things and seeing what happens.  Which can be helpful in coming up with new ideas but is it something we should be doing all the time? Why are you doing what you are doing? What are you trying to find out? What theories do you have about the software and what are they based on? Are they facts, instincts or just because someone told you to

🐦🧵  All in or all out: remotes working is here to stay but probably not everywhere. Good thread on why it works somewhere and not others. Hybrid (some in the office and some out) just doesn’t work very well. From my experience the remote person either gets forgotten or just has a terrible experience trying to hear the people in the office. We tried group cameras, all sorts of mic rigs, always on cameras etc nothing worked to keep the remote people included. The only way it works is everything is remote first no matter where you are. That’s headsets, camera and chat clients for all conversations. It’s the main reason it’s working now as there is no other way to communicate 

📰 Chips and Geopolitics The product architecture and integration diagram (figure 5-1) can actually be thought of as an end users quality measure diagram. The end users in this case are business users and the quality metrics at play are good enough performance/features sets of the product being analysed. This could be really useful if you work in a B2B organisation and trying to understand how your customers see your product. If quality is value to someone then quality in this case is good enough performance and someone is a business users.

📰 https://kanyi.blog/2016/07/30/risk-at-sea the concept of “risque” as we understand it wouldn’t have made much sense to the 19th century sea going merchants. In their time it was related to the financial risque that they took by going to sea to transport goods. For which insurance was created to offset the losses made. 

🐦🧵How the podcast ecosystem works Podcast are open and essentially hosted by the creators (or system that does it for them) Spotify are offering something quite different to the open model. They’re intermediating between the podcaster and the users. Why? So you can start adding in targeted advertising. Much in the same way Facebook and Google do. But this will only work if what Spotify offer is actually better then what is out there. So they need to get podcaster onboard on one side (look better tools and ways to make money!) and users on the other (look all the best podcasters In one place no more hunting around!). Once Spotify can show they can target listeners the advertisers are not going to be far behind and Spotify can sit in the middle taking a skim. It’s called aggregation theory. The interesting thing about this is it’s usually a better experience for all those involved (podcaster, advertisers and users) unless the podcaster wants to build a direct relationship with their listeners…

18th May

📚 Leaders Eat Last via Headway App (Scroll to the bottom to find out what Headway is). There was some interesting ideas around brain chemistry and the idea of shellfish and selfless chemicals. With some citations and references I’d probably get behind these idea but this digest provide none.

Along with this the book has some good ideas and I buy into relationships being key to good leadership but it’s difficult to work out how much of the book is the author’s opinion and how much of it is based on research and/or experience. I don’t think I could recommend this book based on this digest. Which raises another question. Is this because of the author of the book or the author of the digest

⚗️ Agile Manchester: Tester Edition Summary of the talks I attended and why they are relevant to testers. Testing doesn’t always look like testing…

 👩‍🏫 Agile Manchester Overall: Peep show conference – My first virtual conference which was pretty much as I expected: 

  • 👍 Talks that start and finish on time and are easy to see and hear for everyone.
  • 🤷‍♀️ very little audience interaction during talks, passing opportunities to meet other people, see what others thought, breakup your usual week

You can find my very rough notes here… 😉

It’s almost like being at your own personal conference. You know others are there but everyone is in their own little booth watching the talks in isolation. A peep show conference. It’s not necessarily a bad thing just very different when compared to in person conferences. By the end I was very much screened out. Each talk for me felt even more full on then in real life and being sat in front of a screens all day had taken it toll for me. So come 6 o’clock I’d had enough and didn’t attend the virtual social events which may have given me the networking opportunities I mentioned above. 

The day after the talks  Having had some time to digest the talks the day before the following things stood out for me: 

  • Wipe developers machine regularly from fight code and team rot with continuous improvement 
  • Use forecasting to give predictions on when we’ll deliver from agile metrics for predicting the future 
  • What stories are you telling yourself from crucial conversations 
  • Document the implicit from leading a agile organisation through hyper-growth 
  • Let the participants drive the workshops not you from coaching from the back of the room 
  • Communication is the glue of our organisations this can be nurtured, don’t leave it to nature from code + culture ≠ delivery 

Now that’s not to say that was all there was from the talks. There was lots to unpack from them all which you can read above in my notes. For me the two standout talks where agile metrics for predicating the future and coaching from the back of the room. These are two areas I looking at right now. But still enjoyed hearing crucial conversations, leading a company through hyper-growth and code + culture ≠ delivery. Software teams in general would also get a lot out of fighting code and team rot which was succinctly delivered. 

11th May

If you want testers to be 💪 confident in the 🤖 automation then either 🎥 “show” them how it works or build 🤝 trust in the person doing the work. Better yet do both 🤖+🎥+🤝= 💪 💪 https://www.jitgo.uk/building-confidence-with-automation

 📰 The real lord of the flies What would happen if 6 boys where left on an island for a year. The twitter thread is worth a read too with some interesting facts about the original author of lord of the flies. 

🧪 So google do have testers! But they’re actually developers working on code level tests and tools; no exploratory testing in sight. They call themselves Test Engineers which makes more sense when you think of Software Engineers. One focuses on software the other on testing but both use engineering (code) to do their jobs. 

🔈Bad is stronger than good We focus more on negative things than positive. Which is probably useful if you’re living as a caveman and the negatives things can kill you where as the positive things mean you just stick around a little longer. Not so sure how helpful this is in office based situations. Original paper is worth a read too. 

8th May


🔈 The planning fallacy Why things always take way longer than anyone thought. The planning fallacy is a tendency to underestimate the time it will take to complete a project while knowing that similar projects have typically taken longer in the past. So it’s a combination of optimistic prediction about a particular case in the face of more general knowledge that would suggest otherwise.

📰 Product vs. Feature Teams A big telltale of a feature team is the product road maps with prioritised list of features that teams needed to deliver. I think a lot of teams want to become product teams but teams have never had the full autonomy led by their product manager to focus on outcomes. It feels like they get stuck grooming the backlog for the team rather then helping the team focus on what’s valuable to users and the business. Speaking of autonomy…

📰 Follow up to Spotifys failed Squads from last week: Spotify Vs Fitbit Spotify had a lot of autonomy but you need that for innovation. If you have too much control you end up with FitBit which delivered what someone in the company asked for but at the cost of autonomy. Which could have created new opportunities for FitBit via innovation. 

📚 The five dysfunctions of a team via the Headway app. You should read this book. Letting just one of the dysfunction occur can cause a snowball affect and open the door to the others. Start with building trust and accountability and then work step by step on the others to build well performing collaborative teams. Which links back to product Vs feature teams. How do you give teams the autonomy without is leading to chaos. Well one way is to avoid the 5 dysfunctions 

1st May

📹 How falling behind can get you ahead Kind and wicked learning environments sounds like a intriguing concept.  I think software development in teams is a wicked learning environment so what can we do to make it kinder? 

📖 The Coaching Habit via Headway Great introduction to coaching and questions. This is a book that is definitely worth reading rather then just a digest. The 8 questions that the author recommends are all themes that I’ve seen from other books so are not just picked at random. The reasoning behind the questions also backs up other theories especially from Coaching for Performance whose author is considered one of the founders of modern coaching methods.

📰 Spotifys failed Squads 🤭 “Spotify had teams it called squads because it sounded cooler (not joking)”.  “The Spotify model” was what they wanted not how it actually was and failed in parts when they tried to implement it.  

How to break the rules?

Dan North gave a really interesting talk at last years GoTo Conference called How to break the rules.

He takes Eliyahu Goldratt 4 steps of how technology is adopted which he presented in a series of lectures he gave on why people didn’t take on his ideas of theory of constraints (TOC) from his book The Goal.

Eliyahu stated that organisation need to go through 4 steps before a new technology can be successfully adopted:

  1. What is the power of the technology
    • What does it do for you?
  2. What limitation does the technology diminish?
    • What will it make better
  3. What rules enable us to manage that limitation presently?
    • And how much are we wedded to those rules
  4. What new rules will we need?
    • For the technology to succeed

Dan than takes these 4 rules and applies them to real companies that either succeeded or failed to take advantage of new technologies. The interesting part is for the companies that failed what rules (part 3) they needed to break to make use of the new technology.

I’ve made my rough notes on the talk available below but I highly recommend watching it.

 

My notes from the talk:

Talks about The Goal (book) and Beyond the Goal – lectures by Goldratt

  • Series of lectures about 20 years after The Goal was released
  • He tries to attempt to explain why people didn’t apply his Theory of constraints successfully if at all.

First two lectures are: How to adopt Technology?

What is technology: The application of knowledge

For it to be adopted then answer these questions:

  1. What is the power of the technology
    • What does it do for you?
  2. What limitation does the tech diminish?
    • What will it make better
  3. What rules enable us to manage that limitation ?
    • How much are we wedded to those rules
  4. What new rules will we need?
    • For the technology to succeed
He then goes on to apply these questions to real companies.
  • MRP – first application of computers in a business situation
    • Calculated cost of materials for manufacture DuPoint
    • Which allowed them to ship faster then others
    • But when the competition tried it they couldn’t compete as to take advantage of the system you need to change the rest of your business
  • Goes on to apply to ERP and
  • Cloud computing (orgs moving to it)
  • But also Continuose delivery

Interesting: Dell becomes as big as it did because it could work in smaller batches then the competition . All the others companies offered you a fixed machine. Dell changed this by going online only and allowing you to customise your PC and could ship faster than the competition.

Swedish  saying: When talking to farmer use farmers words
  • Commenting on how we collaborate across divisions
  • If you want to collaborate successfully you need to either be speaking the same language or use words the other understands

A lot of organisations are failing with Agile/Kanban/Scrum etc because they still have all the exiting rules in place (see point 3 earlier).

To be able to adopt the new technology you need to move to the new rules (point 4) otherwise you’re still doing the same thing.

Used the example of Amazon not doing Cost accounting and moving to throughput accounting and flow of value

  • Cost accounting is what each department cost
  • Through put accounting is what is being produced by the department and what value does that provide

The problem with step 3 is that it eventually becomes the culture of the organisation and trying to unpick it then is really hard.

So How to break the rules?

  • Understand the power of technology
  • Recognise the limitation the technology will diminish
  • identify the existing rules we use to manage the limitation
  • Identify and implement the new rules

Summary

Another great talk from Dan and goes to show a lot of our problems in software development have been issues in other industries.

Not only that they have been solved  but we tend to overlook them as they don’t look like our industry. What has manufacturing  got to do with writing software? In all don’t take my word for it go watch the talk and start having a look at Eliyahu Goldratt body work. He was onto something…

How to keep up to date with the testing industry?

I recently spoke at UKStar 2018 and the team there asked me a few questions on how I keep up to date in Testing and the industry as a whole which I’ve reproduced here.

What is your favourite testing book/blog? Why is this your favourite?

Two books come to mind. The first is Thinking Fast and Slow by Daniel Kahneman. This book is about how we make decisions and the fact that we are not really all that good at doing it, let alone realising what we are basing our choices on.

Secondly is the Freakonomics set of books by Steven Levitt and Stephen Dubner. Freakonomics is a great way to see how you can go about answering questions that seem impossible at first; but by using some more unconventional methods, you can answer almost anything.

What I enjoy about these books is that neither of them are about testing or software development but the questions that they both aim to answer are so relevant to the work we do.

How do you keep up to date with the software testing industry?

Whenever I’m asked this question it reminds me of what Martin Fowler always says to engineers when they ask him how do they become a better developer? His response is always  “understand the business that you work in”. So rather than focusing on testing I take a broader view and look at our industry as a whole.

I tend to follow a number of bloggers whose insight into our industry I have found invaluable.

Ben Thompson’s Stratechery blog has some excellent indepth analysis on the software industry as a whole and how some of the larger organisations (Google, Amazon, Facebook, Apple etc) operate.

Benedict Evans weekly newsletter and Charles Arthur’s daily Overspill site are also great for finding technology focused articles from around the web that you probably would have missed, or never even come across, always with some illuminating commentary.

Twitter is a great source of information too. I tend to build up my feed by following people both inside and outside of the tech industry to get a broad range of ideas and influence.

What is the biggest misconception about testing that you’ve heard?

That automating all your testing will speed up the delivery of your products. A lot of teams still see testing as that bottleneck at the end of development stopping the release. So if you automate all your testing you will be able to ship faster.  

What they almost always fail to see is that their releases are either too big so the test team can’t isolate and feedback on the risky areas or they still see testers as simply running check lists against the product. Hence thinking that they can be replaced with automation. Tester’s always do so much more than this but their work has had a history of being boiled down to “Have all the tests passed”.