I think, well I hope, that now, the romanian people will realize what they have lost. But the people still has the King’s family, the Romanian Royal Family. This Royal Family is his work, made with great love for his country.
http://www.familiaregala.ro/stiri/articol/his-majesty-king-michael-of-romania-has-died
I already spoke about inattentional blindness in the context of testing in a previous post: Inattentional blindness and test scripts. But there are implications also for code reviews.
So, “We asked 24 radiologists to perform a familiar lung-nodule detection task. A gorilla, 48 times the size of the average nodule, was inserted in the last case that was presented. Eighty-three percent of the radiologists did not see the gorilla. Eye tracking revealed that the majority of those who missed the gorilla looked directly at its location.”(1)
But how can the effects of inattentional blindness can be reduced?
”A more effective strategy would be for a second radiologist, unfamiliar with the case and the tentative diagnosis, to examine the images and to look for secondary problems that might not have been noticed the first time through.”(2)
So, it does make sense to do a code review because things might have gone unnoticed. But with complex systems the important thing is the granularity. This means that we have to understand who makes the review and see possible implications.
For example, let’s say a novice has written some code and another novice will make a code review. The junior reviewer, possibly, will understand where and why that code was written like this. But is it enough? I would say no. A senior/advanced developer have to review the code because:
– can share experience;
– has deep technical knowledge(oop, architecture, clean code, properly deal with legacy code, TDD, unit tests, algorithms);
– is capable to have more perspectives.
Is this still enough? I would say no. A tester can take a look at the code with the intent to help him/her with the testing.
There are some lessons here:
– a novice can participate to a review because is a good occasion for him/her to learn. It will also offer a good occasion to be aware of the context and give a feedback;
– is not ok when the code review is not made by a senior because slowly slowly things will get in such a bad shape that it will be difficult to repair;
– a senior developer might miss certain details;
– a manager should not feel comfortable just because the process does not allow a commit of code in source control without reviews. Even if that process might say something like this: “a review must be made by at least one senior developer”;
– it is related to testing in the sense that the tester is searching for information which will be used in designing the tests;(3)
– this should not be used by developers as an excuse for a lack of professionalism.
This is praxis(4)….
(1) Trafton Drew, Melissa L.-H. Võ, and Jeremy M. Wolfe, Psychological Science September 2013;24(9):1848-1853, “The Invisible Gorilla Strikes Again: Sustained Inattentional Blindness in Expert Observers”: http://search.bwh.harvard.edu/new/pubs/DrewVoWolfe13.pdf
(2) Daniel Simons Christopher Chabris, “The Invisible Gorilla” https://www.amazon.com/gp/aw/d/B009QTTYCQ
(3) James Bach, Rapid Software Testing class discussion [2017]
(4) Dave Snowden, “Of practical wisdom”: http://cognitive-edge.com/blog/of-practical-wisdom/
“We asked 24 radiologists to perform a familiar lung-nodule detection task. A gorilla, 48 times the size of the average nodule, was inserted in the last case that was presented. Eighty-three percent of the radiologists did not see the gorilla. Eye tracking revealed that the majority of those who missed the gorilla looked directly at its location.”(1)
We think we pay attention to things but it’s not like that. We’re aware of only a small part of what we see at any moment. So we might even look at something and not be able to see it – it seems eyes actually look at something but without actually seeing it.
Initially, when I thought about test scripts in conjunction with the concept of inattentional blindness, I imagined it was a way to disprove test scripts entirely. I say this because of the following logical reasons:
– If a test script is being followed with great precision, then for sure other things are overlooked. Therefore, this means the script is not a very useful technique;
– But if the tester says that it will also check other things that are not included in the test script, in a way this behaviour invalidates the test script.
In other words, these two approaches practically invalidate the idea of a test script.
I admit I was biased with test scripts because I saw it (and I still see it) applied in a very very wrong way.
James Bach surprised me by saying that, actually, test scripts are an advanced test technique that should not be done by novices(2).
An advanced tester is aware of his/her limitations and makes sure that the testing is not affected in a bad way when using test scripts.
The reason why a junior tester should not receive test scripts is because, the likely scenario is that the test scripts will not be run as they should be(2). A junior/novice tester should be guided/accompanied by a senior tester.
This is praxis(3)….
(1) Trafton Drew, Melissa L.-H. Võ, and Jeremy M. Wolfe, Psicholigy Science September 2013;24(9):1848-1853, “The Invisible Gorilla Strikes Again: Sustained Inattentional Blindness in Expert Observers”: http://search.bwh.harvard.edu/new/pubs/DrewVoWolfe13.pdf
(2) James Bach, Rapid Software Testing class discussion [2017]
(3) Dave Snowden, “Of practical wisdom”: http://cognitive-edge.com/blog/of-practical-wisdom/
Let’s try an experiment(1):
Scrum Master = Manual Scrum Master
Programmer = Manual Programmer
Project Manager = Manual Project Manager
Product Owner = Manual Product Owner
Team Lead = Manual Team Lead
Technical Lead = Manual Technical Lead
Delivery Manager = Manual Delivery Manager
Security = Manual Security
Marketing = Manual Marketing
Coach = Manual Coach
Trainer = Manual Trainer
Mentor = Manual Mentor
CTO = Manual CTO
CEO = Manual CEO
Is not ok, isn’t it?
Maybe this is happening because it is not known what a tester should really do and what testing, professional testing, actually is.
But is also sad that with all the agility we left the professional testing outside and this is not ok.
I am glad that Robert C.Martin has spoken about this. In a way he begun to heal the divide between agile and professional testing (Context Driven Testing, Rapid Software Testing). Below you can find reproduced an entire blog post written by Robert C. Martin:
“James Bach gave a stirring keynote today at ACCU 2010. He described a vision of testing that our industry sorely needs. Towit: Testing requires sapience.
Testing, according to Bach, is not about assuring conformance to requirements; rather it is about understanding the requirements. Even that’s not quite right. It is not sufficient to simply understand and verify the requirements. A good tester uses the behavior of the system and the descriptions in the requirements, (and face-to-face interaction with the authors of both) to understand the motivation behind the system. Ultimately it is the tester’s job to divine the system that the customerimagined; and then to illuminate those parts of the system that are not consistent with that imagination.
It seems to me that James is attempting to define “professionalism” as it applies to testing. A professional tester does not blindly follow a test plan. A professional tester does not simply write test plans that reflect the stated requirements. Rather a professional tester takes responsibility for interpreting the requirements with intelligence. He tests, not only the system, but also (and more importantly) the assumptions of the programmers, and specifiers.
I like this view. I like it a lot. I like the fact that testers are seeking professionalism in the same way that developer are. I like the fact that testing is becoming a craft, and that people like James are passionate about that craft. There may yet be hope for our industry!
There has been a long standing frission between James’ view of testing and the Agile emphasis on TDD and automated tests. Agilists have been very focussed on creating suites of automated tests, and exposing the insanity (and inanity) of huge manual testing suites. This focus can be (and has been) misinterpreted as an anti-tester bias.
It seems to me that professional testers are completely compatible with agile development. No, that’s wrong. I think professional testers are utterly essential to agile development. I don’t want testers who rotely execute brain-dead manual test plans. I want testers using their brains! I want testers to be partners in the effort to create world-class, high-quality software. As a professional developer I want – I need – professional testers helping me find my blind spots, illuminating the naivete of my assumptions, and partnering with me to satisfy the needs of our customers.”(2)
(1) Michael Bolton, “Manual and automated testing”: http://www.developsense.com/blog/2013/02/manual-and-automated-testing/
(2) Robert C. Martin, “Sapient Testing: The “Professionalism” meme”: https://sites.google.com/site/unclebobconsultingllc/home/articles/sapient-testing-the-professionalism-meme
Usually, in sprint planning comes a moment when developers and testers have to give an estimation. After the tasks seem to be clear, the testers and developers give their corresponding story points. What seems strange to me was the fact that these estimations are calculated and a single number is created.
For me, this approach seems like comparing apples with pears and then generating a number.
I imagine a lot of agilists will say that this is working. I would say: maybe. What gave them the impression it works? Well, I saw that human nature is capable to cope with formal non-sense, so that, then, informally, make it work, one way or another. Why? Well, because, sometimes, a lot of energy is lost in convincing some people of some strange truths. Truths that are not in trend but for the moment might seem easier to cope with. Why? Well, because of laziness, fear, workload, or just because it’s safer….
For me, developers and testers worlds are very different. Yes, these worlds can intersect somehow, but they are still very different like two oceans uniting/meeting each other.
For a developer, when he/she knows what to solve and how to solve it, the task is easy, and the code is written. That code should behave in a deterministic manner. The developer might write unit tests and/or integration tests – from a tester perspective these are automated checks not tests(1). And when I say developer I am thinking of an XP developer, of a developer who should aim at what Uncle Bob says(2).
For a tester things are different. Although things might appear to be clear for the same story, we might deal with non-determinism. When I say tester I am thinking of a tester who is part( consciously or unconsciously) of Context Driven Testing(3) school, for example a Rapid Software tester(4). Testing actually poses a need for a very different skillset because the problems the tester encounters have a different nature, compared to the ones a developer faces. So even if a developer has modified just one line of code, a tester can spend days and days if she/he decides to make a deeper testing, and not just a shallow one. Why? Because the code is, usually, surrounded by a larger code context that might affect the stability of the product. But if is just one line of code, why would it take a lot of time? A small cause can have big effects. For example, does the developer know with great precision all the details, internal technical details of the code? A simple data type problem can cause one of the strangest and ugliest effects and it all starts from just one line of code.
Therefore, I think we should be careful what we do, and we shouldn’t be reluctant to raising questions, even if we might be wrong. I consider this approach of combining numbers that mean different things, a fallacy. For me, this is an oracle(5) to spot the problem and, why not, I have a name for it: Two oceans integration.
(1) James Bach, “Testing and Checking Refined“: http://www.satisfice.com/blog/archives/856
(2) Robert C. Martin, “The Programmer’s Oath”: http://blog.cleancoder.com/uncle-bob/2015/11/18/TheProgrammersOath.html
(3) Context Driven Testing: http://context-driven-testing.com
(4) Michael Bolton, “What Is A Tester?”: http://www.developsense.com/blog/2015/06/what-is-a-tester/
(5) Michael Bolton, “Oracles from the Inside Out, Part 1: Introduction”: http://www.developsense.com/blog/2015/09/oracles-from-the-inside-out/
I begun to learn about testing because I was blessed to work with some really good testers in my life. Because of that, I wanted to learn more, in order to make my interaction with them more fruitful. If I am a better developer it’s also because of them. I am glad that I have met them first, because afterwards, life showed me also the unprofessional testers. This made it possible for me to be able to compare, analyze, see…
Learning about testing helped me:
Allen Holub published an interesting post:
“Should we just give up on the Scrum Guide? Nobody’s read it.
To me, the Scrum Guide is the definitive definition of Scrum. However, I’ve found (by asking many people, sometimes very large groups at conferences) that most Scrum practitioners have not only never read the Guide, they’ve never even *heard* of it. Put another way, Scrum as practiced has little or nothing to do with the Guide. So, given that, is the Guide even relevant? I’m just as guilty as most in quoting chapter and verse when somebody says something ridiculous about Scrum, but more often than not, the thing they’re touting (story points and velocity, for example, or “sprint commitments”) is considered central to Scrum by the vast majority of practitioners, even if it’s either not in or is in direct opposition to something the Guide says. Given that, do you think that it’s worth referring back to the Guide, or should we just define Scrum as what people actually do and get off our high horses?”(1)
I deeply agree with Allen Holub. I am, as personal experience, also amazed by this. Each time when there is a discussion regarding a certain topic related to Scrum I advise them to open the Scrum Guide and have it as reference.
But even after it is being read, by some, did they really understood it? For example in the Scrum Guide there are lots of interesting and deep topics, for example:
– “complex adaptive problems” -> this points to an entire discipline regarding complex systems;
– “Facilitating” -> A two days workshop can be made only to understand what facilitation is.
Arie van Bennekum, co author of Agile Manifesto, does this. Interesting and deep thoughts also Dave Snowden has about this subject.
And these are just two examples from the Scrum Guide.
But is even more, I speak about history of Scrum like writings of Nonaka.
I begun to have reluctance of the so called Agile Coaches who actually know only Scrum but when you dig deeper actually they do not know about Scrum neither.
But a bigger problem is that a lot of people in industry think Scrum=Agile and is not like this at all. Scrum has it’s place like the other agile methodologies.
So, ‘Should we just give up on the Scrum Guide?’ I hope not. We should encourage people read the Scrum Guide and then to think upon it. Is useful, it provides a common ground when speaking about Scrum. Also, I consider the guide a very condensed/compressed information waiting to be unrolled.
(1) Allen Holub, “Should we just give up on the Scrum Guide? Nobody’s read it.”: https://www.linkedin.com/groups/37631/37631-6340348761025454083
(2) Scrum Guide: http://scrumguides.org/scrum-guide.html
Preetam De wrote something interesting which made me think to complex systems:
“#Transformation is a process.
#Evolution is a learning experience through empiricism.
Reason why transformations have short term benefits.
Evolution is long term and is based on how the ecosystem is changing.
Are you transforming or evolving?”(1)
Since we deal with complex dynamic systems ‘coevolution’ word came in my mind. And I would say that near empiricism we also have theory which could help us a lot. ‘Transformation’, maybe, has short term benefits because a mechanistic approach is considered. ‘Evolution’ works better, maybe, because we use another metaphor which is ecology, biology.
This means the techniques used for ‘transformation’ are different than the ones used for ‘evolution’. No wonder that we have problems with scalability when ‘transformation’ should be applied at large scale.
Note: I know there is a place for both but the problem now, I think, is that we only see the mechanistic approach.
(1) Preetam De, Linked In post regarding ‘transformation’ and ‘evolution’ https://www.linkedin.com/feed/update/urn:li:activity:6340146166902059008
In 2001, in Snowbird, when Agile was defined there were also representatives from FDD(1), DSDM(2) you can see it in agile manifesto history (3).
Try to search for Project Manager in the FDD and DSDM references….
So, if I am following a good logical deduction actually “Agile Project Manager” should make sense. I think Agile Project Manager does not make sense because we are still not able to transcend certain things.
Now we’re still speaking in terms of Scrum Masters and Agile Coaches and …. unable to accept things which existed from the beginning and still exists, if I can say so.
I wonder how many of so called agile folks know/read/understood or even applied FDD, Crystal, DSDM, XP….
Side note: When I speak or hear discussions about Scrum, especially when Scrum Master(s), Scrum Coaches, PO’s, management people are present, these 3 words pop into my head: “complex adaptive problems”(4). These three words combined in this way is a condensed information of an entire discipline. Are they aware of this? If yes, should this be seen in their actions?
(1) FDD: http://www.nebulon.com/articles/fdd/latestprocesses.html
(2) DSDM: https://www.agilebusiness.org/content/roles-and-responsibilities
(3) Agile Manifesto, history: http://agilemanifesto.org/history
(4) Scrum Guide: http://www.scrumguides.org/scrum-guide.html
Shu: So, we need a Scrum Master(SM) on project Z
Ri: Are you sure you need a SM?
Shu: The other one left….So we need someone to take care of the team and make sure the project will be ok…so yes.
Ri: Hmmm
Shu: What?
Ri: Isn’t that too restrictive, just a SM?
Shu: What do you mean? It’s a Scrum team, so we need a SM since the other one left.
Ri: Yes, but you also need a person to make sure that things will be ok, a person you can contact when things go wrong
Shu: Yes, a SM
Ri: Don’t you feel a divergence?
Shu: Divergence?
Ri: When you say “SM” and to “make sure the project is ok”, you practically define how the project should always be managed. Aren’t you limiting what she/he should do, although you want much more?
Shu: Its Scrum. Its clear/standard stuff. Everyone knows what to do and what to expect.
Ri: And what will happen when ontology changes? What will be her/his epistemological response? Can you be more clear in your need?(1)
Shu: Ha? Why did you use those words?
Ri: Because of neuroscience. By using those words I tried to activate different neural patterns so maybe you will see things differently. Look, its simple: ontology – a type of system; ontologies – different types of systems. Epistemology – how we know stuff. (1)
Shu: So I need someone to take care of the project but who is able to play also the SM role when applicable or whatever. To be aware of the different ontologies, to transcend them.
Ri: Are you sure? I’m kidding. Its better. At least you tried to understand what you need, and you also started to challenge what you know and what you need to know about a SM.
(1) Dave Snowden, “Multi-ontology sense making; a new simplicity in decision making”: http://cognitive-edge.com/articles/multi-ontology-sense-making-a-new-simplicity-in-decision-making/
(2) Alistair Cockburn, “Shu Ha Ri”: http://alistair.cockburn.us/Shu+Ha+Ri
