A friend of mine always say the biggest problem with software is that bad software still works. But what about when software makes you sick? Or creates completely new businesses that profit from the strict and inflexible nature of software? I very much enjoyed this article in The New Yorker by @atul_gawande.
“…patience as a personality trait is modifiable. Even if you’re not a particularly patient person today, there’s still hope you can be a more patient person tomorrow.”
Me and Teddy Zetterlund had lunch last week and reflected on the challenges of working in big organisations. Later he sent me this excellent article by Niels Pflaeging outlining a new theory about the types of leadership (and influence) that exist in an organisation. I immediately started thinking about my situation and those around me and I’m definitely putting this theory in my bag of tools for Agile Coaching.
This weeks reading #3 (It’s too complex, and perhaps too stimulating. But you’ll still make mistakes.)
”All this work had been put into this thing, but it missed the fundamental problems that people faced. And the biggest one that I took away from it was that basically people are playing computer inside their head.” Programmers were like chess players trying to play with a blindfold on — so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself.”
Creating software is, still today, a struggle. Converting ambiguous statements about problems into precise unambiguous instructions for a computer to solve it. Talk to any experienced programmer and they’ll tell you to focus on the problem at hand, not the code. But what if the level of complexity is so high that humans are unable to comprehend it? Self-driving cars, aviation systems, Amazon Web Services, power grid software etc. How can we trust them? In this article you’ll get to know some of the people and programming languages in this field. Because humans are not to be trusted with this level of complexity.
Using game theory Simon Sinek talks about the finite player who wants to win and the infinite player who wants to keep the game running. What happens when you look at companies and nations using that lens? Eg. the United States entered the Vietnam War to win while FNL was in it for as long as it took. The US acted as a finite player and the FNL as an infinite player. Stay with him through the Q&A-part, it contains the most interesting bits.
An hour into their journey on March 28, 2014, the Pokoras crossed the Lewiston–Queenston Bridge and hit the border checkpoint on the eastern side of the Niagara Gorge. An American customs agent gently quizzed them about their itinerary as he scanned their passports in his booth. He seemed ready to wave the Jetta through when something on his monitor caught his eye.
“What’s … Xenon?” the agent asked, stumbling over the pronunciation of the word.
Video games, heists and a moral compass that starts moving in the wrong direction. Brendan I. Koerner’s thrilling story for WIRED has it all:
Rating your ideas according to your confidence in them (not to be confused with your self-conviction) is an interesting method for reducing the number of duds you release to your users. Combining it with breaking down the ideas into their essential parts and scoring them separately also seems to be a good idea to avoid goldplating and extensive over-engineering:
And what’s the difference between focusing on deadlines and focusing on finding the right problem to solve? Can you imagine having your team pitching problems to you as a Product Owner and letting them decided on a course by measuring their business impact? Inspiring indeed.
Sara [10:22 AM] It’s quite faschinating how much the role and identity of being a Tester has changed. I’ve had to change a lot in my “tester identity” these last 10 years.
Sara [10:22] Maybe I’ll write a book about it some day 🙂
Christoffer [10:23 AM] Yes, do it! 🙂 What would you say is the biggest change?
Sara [Today at 10:56 AM] Answering your question @christoffer (and trying to keep it as concise as possible, obviously failing).
My personal path was somewhat like: I started as a developer’s right hand, testing ready code, then moved towards being a tester in agile team, then test lead, then worked on a high level defining quality strategy on organization level, and then returned to the hands-on.
And as for the tester identity change per se (the way I’ve seen it which is 100% subjective), I think there was a very interesting metamorphosis the last 10 years. Testers did not want to be the “passive receivers” of developer’s work anymore, so there was a lot of talk about being an inspiration/guide/ambassador of quality. And that time created plenty of “empty” testers, the ones without strong knowledge and expertise, but with an ambition of some special knowledge and (at last!!!) power. This attitude couldn’t possibly sustain itself long. So naturally the emptiness started filling up with real expertise. But this time it was important to become an equal player of the development process. Which means testers having their own domain of expertise and at the same time share it with everyone else in the team. Not an easy task. But we seem to be managing.
Christoffer [2 hours ago] I notice it’s very common that people struggle in teams between having special knowledge which entails being responsible for all work requiring that knowledge and the teameffort requiring everyone to share/contribute their knowledge and expertise but not necessarily doing the work themselves.
Christoffer [2 hours ago] I guess it boils down to making sure people with special competence feel like they contribute even if it’s not their hands on the keyboard all the time?
Sara [2 hours ago] I guess it’s one aspect of it, yes.Another one I see is somewhat different value attached to different skills. For instance for developers the value is very clear. Code = product. Easy to see and measure, easy to be proud of. For the tester it’s a bit more tricky, because good product quality is not equally straightforward and rather undefined.
Sara [2 hours ago] And in itself testers best effort manifests in helping an organization and a team produce better quality. But just “helping” is not enough, it’s not fully satisfactory, it’s a group result. One also needs some individual result, and this is what testers are searching for — how to have impact on both group- and personal level.
Sara [2 hours ago] IMHO 🙂
Christoffer [2 hours ago] As a developer I used to think that too. Code = product. But as time has passed I’ve realized that Code is at best product. In a lot of cases it’s not. And that’s where developers today should feel like the testers you describe above as well. Is the work I’m doing adding value? Is it solving someones problem or am I creating more problems?
For good developers product is not necessarily code. Good developers solve a problem for someone. And testers can help them understand that problem by framing the problem in a way that’s understandable for both developers and the problem-owner. Using scenarios, scoping and challenges of ideas.
Christoffer [2 hours ago] However, developers have one tool that give them instant continuous affirmation. The red/green bar of a unit/integration test. For testers the affirmation is harder to find, like you say.
Sara [2 hours ago] Interesting about the developers point of view! We continue after lunch 🙂
Sara [1 hour ago] “Good developers *solve* a problem for someone. And testers can *help* them understand that problem..” — exactly my point you replicated here. There is a big gap in terms of satisfaction between “solve” and “help to solve”.
Sara [1 hour ago] So I think both linguistically and empirically we’re aiming to “developers and testers *together* solve the problem”.
Christoffer [1 hour ago] Sorry about that sloppy writing. My thought is good developers help someone with a problem or help them realize an opportunity. Sometimes they solve it for them with software but very often they help the person or organization realize it’s not a problem to be solved with software but rather it’s a tweak in process or just understanding the domain.
Christoffer [1 hour ago] I agree with your second note!
Christoffer [1 hour ago] totally
Sara [1 hour ago] Mhm, I see what you mean with problem solving/sorting as part of developer’s job.
Christoffer [1 hour ago] Much like the testers job of identifying if the software actually solves the problem or if it makes it worse.
Christoffer [1 hour ago] Our different competences aside we are very alike in our aims and struggles.
In the category Most Important Subject I have a hard time finding a presentation more relevant than Kimberly’s. An inspiring tale of what we did in 2017 to turn the climate trend from a negative one to a positive one.
In the category Most Useful At Work I choose Joshua Kerievsky (known from Modern Agile) and his talk about psychological safety as a pre-requisite for creating high performing teams. Showing some of the theories and highlighting concrete things to look for in our daily work.
The last from my Top 3 is Gojko Adzic talking about how our names make computers go bananas sometimes. And the problems you’ll face if your name is Bob Test. Hilarious and just pure entertainment! 🙂
