Start From The Past

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

For a while now I’ve had a rule of thumb, heuristic, that I’ve followed when I’ve wanted to learn something new. I don’t actually remember if I learned it from somewhere or came up with it myself. Nevertheless, it’s been useful for me and I would like to share it with you.

Find Out Where It All Started From

If I want to learn something new, I will focus on the past and try to figure out where it all started from. This way I will lower the risk of being affected by Law of Raspberry Jam.

As for now, I think it’s most helpful if I share couple examples.

Case 1: Scrum

I wanted to know more about Scrum couple months ago. Considering the popularity of Scrum, its Wikipedia article is quite thorough. What’s most important, it has History section in it. Let me copy-paste the beginning of that section:

Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the “New New Product Development Game”.^[1] Takeuchi and Nonaka later argued in “The Knowledge Creating Company”^[2] that it is a form of “organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally”.

After learning that, I went and read the paper. What’s interesting, paper didn’t mention e.g. sprints, daily stand-ups or backlog. It focused more on identifying characteristics. Characteristics that leading companies showed (in 1986). Later, while learning about origins of Scrum, I ended up watching James Coplien’s talk at Youtube: Patterns: The New Defacto Scrum Standard. I’ve seen it several times since then. Perhaps the thing that strike me the most, was that James said how Scrum had been affected by Toyota Production System (a.k.a. Lean).

Learning about the work of James Coplien also led me to Scrum Pattern Community & their published patterns. Based on all the previous, my current understanding is that Scrum is about identified patterns & in the end: Kaizen. Successful teams have had patterns that has been part of their success. Those have been identified and came part of Scrum. It also reminds me that every team has its own context that they operate on. This needs to be considered when trying to apply a pattern (e.g. daily stand-up) to yours.

Case 2: Agile

I’ve also activated with Agile lately (this year). Sure, I’ve been familiar with Agile Manifesto & its principles. That’s though quite simplistic & therefore it makes you wonder how to interpret it. That’s why I wanted to understand what people behind the Manifesto thought about it, when it was published. I found one good article about it where Martin Fowler & Jim Highsmith explained their thinking behind every point & principles. Good to notice how the article is from year 2001, when the Manifesto was published.

There’s a lot more, if you have time, energy & curiosity. Martin Fowler has an interesting article on his website from July, 2000, where he describes the New Methodology. Then there’s also an updated version of the same article from year 2005. I haven’t yet read those. But that’s where I will go next. These are the people who were behind Agile Manifesto, they are the ones whose thinking I want to listen, when learning about Agile.

I would be naive though, if I would assume that agile software development came to life 13 years ago (2001). There’s one great article that reminds us how people were doing things smartly already in mid-1950s. Here’s one quotation (by Jerry Weinberg) from that article (Iterative and Incremental Development: A Brief History):

We were doing incremental development as early

as 1957, in Los Angeles, under the direction of

Bernie Dimsdale [at IBM’s Service Bureau

Corporation]. He was a colleague of John von

Neumann, so perhaps he learned it there, or

assumed it as totally natural. I do remember Herb

Jacobs (primarily, though we all participated)

developing a large simulation for Motorola, where

the technique used was, as far as I can tell, indis-

tinguishable from XP.​​

​​​​

When much of the same team was reassembled

in Washington, DC in 1958 to develop Project

Mercury, we had our own machine and the new

Share Operating System, whose symbolic modifi-

cation and assembly allowed us to build the system

incrementally, which we did, with great success.

Project Mercury was the seed bed out of which

grew the IBM Federal Systems Division. Thus, that

division started with a history and tradition of

incremental development.

 ​

All of us, as far as I can remember, thought

waterfalling of a huge project was rather stupid,

or at least ignorant of the realities… I think what

the waterfall description did for us was make

us realize that we were doing something else,

something unnamed except for “software devel-

opment.”

 ​

Case 3: Testing

 ​

On December, 2013,  I wrote a blog post about history of software testing and especially how first software testing teams were formed. It’s a good description of how testers were starting to came into software development 50 years ago. Because they concluded that it would help if there were people who were focusing more on testing than others.

​

It’s good to note though that I’m talking about software testing. Testing, the mental activity of questioning in order to evaluate – that goes far back. I haven’t put that much effort on tracking the history of that yet.

 ​

While exploring the history of software testing I ran into different kinds of papers. One particular (Evaluation of the Functional Testing of Control Programs from 1967) hinted where the demand for excessively structured testing came from.

 ​

Other way to learn about the history is to ask from people who remember far enough. I asked for example from Jerry Weinberg about origin of test cases.

 ​

This is a good reminder of the context behind birth of test cases. While it may be beneficial to use them in your context 60 years later, do note that access to machines is not that abominable these days anymore. If that’s the case, other reasons for using them need to be considered. This same thinking should apply to anything that you’re leaning into & haven’t invented by yourself.

​​​

Try It Yourself

 ​

Next time you want to learn about something new (e.g. BDD, Specification by Example, Exploratory Testing, Lean, Unit Tests), start from its history. If there are few people who are behind it, try to find what they have to say about it. Or perhaps you can even ask from them via email, Twitter or some other way. This way you’re increasing your chances of understanding the subject the same way as the people who came up with it.

 ​

Good luck!

 ​

To show that I’m not alone, I’d like to end this to Martin Fowler’s words:

 ​

In order to understand something, I often find it useful to know how it came about.

 ​

Advertisement

Three Days of Kobayashi Maru

Belongs to http://en.memory-alpha.org/wiki/Kobayashi_Maru

Those of you that have not watched Star Trek, are not probably familiar with Kobayashi Maru. Wikipedia defines it like this

It is a Starfleet training exercise designed to test the character of cadets in the command track at Starfleet Academy.

Rescuing the civilian vessel Kobayashi Maru is the notional primary goal in a simulated battle with the Klingons. The disabled ship is located in the Klingon Neutral Zone, and any Starfleet ship entering the zone would be in violation of the Organian Peace Treaty.

The approaching cadet crew must decide whether or not to attempt rescue of the Kobayashi Maru crew – endangering their own ship and lives – or leave the Kobayashi Maru to certain destruction.

Overall you will be put into a situation where you have – seemingly – no-win scenario ahead of you. Test will test how you will handle the situation. As there is no one right solution and you are under pressure, your actions will reveal your weaknesses (and strengths).

My personal Kobayashi Maru (a.k.a. Rapid Software Testing -course)

Last week I spent three days at Rapid Software Testing -course held by James Bach at Helsinki. After the course I realized that the course was like Kobayashi Maru. Lots of different challenging tests that had us go through situations that didn’t have one right solution. We didn’t have to sacrifice our crews, but we had to figure out how we can test our products as well as we can with our given resources.

The tests (or challenges) also revealed a lot about ourselves. At least it did in my case. I was lucky to have some sort of reputation which led to James knowing me in advance. This on the other hand led to me being given more challenges than perhaps anyone else on the course. Someone might see this as a negative side, but I thought (and still do) I was privileged to participate to those. So what did those challenges reveal about myself? At least these things:

• I can control myself rather well when being questioned and criticized (to certain degree)
• Even under pressure I can solve problems
• I’m able to listen other peoples suggestions (by colleagues for example) about solving the problem
• I need to have deeper knowledge of testing techniques (in a level that is available even under pressure)
• I have a habit of forgetting details under pressure so I need to make sure I have resources that help me coping with my weaknesses (e.g. screen recording and notes)
• I need more experience of different testing problems
• I need to create (or find) heuristics that help me perform under pressure and when dealing unfamiliar subject
• I especially need to develop my ability to ask questions that help me perform the task given (this is related to previous one)
• I need to stop making assumptions! (About things that matter)

Assumptions

Photo by Jacob Bøtter. Used under the Creative Commons license.

If there is one thing I want to raise out of the course, that is definitely making assumptions. The problem that I faced again, again and again during my challenges.

I kept thinking about it and especially why I ended up in that assumption trap several times.   First I realized that when we are under pressure, we are not thinking logically always about the situation. I mean stopping for a minute and think what we are being asked of. The challenges that I was given – and face in my job on daily basis – ask me to solve something. Before you can move into solving the tasks, you need to be rather confident about the fact that you have understood the given assignment as the one who gave it understands it.

If someone asks you to “test this door”, you need to be sure that the door you are going to test is the one you were being asked to test to. Secondly you want know what the person who asked you to test the door really wants. What sort of information is he interested of? Does he want that through that door needs to be accessed 24 hours 7 days a week? Or that it is enough secure to keep people from breaking in? If you just jump into testing the door, you will make assumptions on the purpose of your testing and the needs of the person asking for the testing.

In the end assumptions are a tempting and easy way of doing your job. It’s so tempting to just go with your assumption instead of having the trouble of asking the questions that will test your assumption. But as testers it is our responsibility to test our assumptions. Because if we don’t do that, who will? How can we held our heads high and look back with confidence if we haven’t saw trouble of testing our assumptions? Think about it the next time you discover you have been following an assumption that led you into trouble. What question should you have asked and what point?

Impossible is possible

McFadden, Strauss, Eddy & Irwin (public relations firm) for Desilu Productions.

Wikipedia tells about James T. Kirk’s attempts to beat the Kobayashi Maru:

James T. Kirk‘s back-story defines that he took the test three times while at Starfleet Academy. Prior to his third attempt, Kirk surreptitiously reprogrammed the simulator so that it was possible to rescue the freighter.

This fact finally comes out in Star Trek II: The Wrath of Khan, as Kirk, Saavik and others appear marooned, near death. Saavik’s response is, “Then you never faced that situation…faced death.” Kirk replies, “I don’t believe in the no-win scenario.” Despite having cheated, Kirk had been awarded a commendation for “original thinking.”

Kirk doesn’t believe in no-win scenario and therefore he will find a way to solve a problem, no matter what. As a tester I want piece of that mentality. We have to respect the laws and act ethically, but otherwise there is a lot room for creativity and bending the rules. Even as simple as asking the programmer if he can provide us a logging functionality for a product. An act that can help our testing a lot but is not an option for several people. Or they don’t see it as an option (“it’s impossible” / “he will never do that!”).

During the RST-course I had several moments where I did not use all my resources. I was too busy trying to figure out the solution inside my head. When instead I should have considered how I can get the answer without figuring it from scratch myself? Who has the information? Who can help me? Asking for help is not sign of weakness (to a certain degree). Not being able to ask for help IS a sign of weakness.

I also gave too much respect on my thoughts about what I can do and can’t do. Who is stopping you to do whatever you prefer (with respect to laws and ethics) to solve the problem in hand? And if you are being stopped, at least you have tried and learned something.

De-Focus!

Last thing I wanted to mention from the course is de-focusing. I’ve found it to be rather powerful technique for varying your testing. First of all frustration is the emotion that

Creative Commons Attribution

triggers de-focusing. When you are frustrated and don’t see progress in your testing, you rely on de-focusing. Find pattern in your previous tests and then violate that pattern as much as you can. Prefer MFAT (Multiple Factors At a Time) and vary your observations as well. Observe for sections that you previously did not. Imagination is the limit here.

I witnessed several times during the course that de-focusing helped to solve a problem and will use it on my work also. It can be as simple as using random numbers or help of a colleague, but breaking the pattern is the point.

Few words about James Bach

I’d like to end my post by saying few words about James Bach. I had heard a lot of things about James and knew his reputation as an aggressive and difficult person. At least that’s the impression I had. Before the course started I had a hunch though that James can’t be as bad as his reputation is. I mean, who would hire him as a consultant?

And my hunch was correct. I felt that James was probably the best teacher I’ve had. Amazing amount of knowledge and experience of our field and also entertaining, but demanding style of teaching. I talk about teaching, but he actually enabled me to learn. I had my hard times on being pressured by him but accepted it as a way to learn more. And, boy did I learn. Still have those moments of hard questioning by him clear in my mind. Because of those experiences I was able to find immediately after the course few critical bugs in my current project.

I hope I’ll meet James again at Let’s Test 2013 along with all the other great testers. All these people like James show me the journey I still have ahead of me as a tester, but also motivate me to surpass them.

Ut tensio, sic vis

Preface

British physicist Robert Hooke published Latin anagram in year 1660:

ceiiinosssttuv

No one managed to though figure out what it meant and therefore it took 18 years (1678) until he revealed the solution to it:

Ut tensio, sic vis

Which can be translated as: As the extension, so the force. 

Hooke’s law is a law of elasticity and Britannica for example defines it like this:

For relatively small deformations of an object, the displacement or the size of the deformation is directly proportional to the deforming force or load.

At this point some of you might be wondering why I am explaining the law of elasticity here. The reason is, that I think it is a great methaphor for an online course I just attended. The course is BBST Foundations and it is held by the Association for Software Testing. It lasted one month and I’m still waiting for my final grade (pass/fail) for it.

In my opinion, the course was like a spring. The more I put effort on studying and interaction with other students, the more the course gave back to me (and hopefully to others as well). I can also assure that I was far from reaching the elastic limit of the course.

Via Dolorosa
Before I move on to explaining all the things I loved about the course and what I’ve learned, I want to say few words about the journey and especially how hard it was for me.

Few months ago I tried to google information about this course, and especially the amount of time it will take, but I did not find much specific details about it. Sure I found estimations that said it will take 10-40 hours per week, but those were just numbers to me then. I want to bring up how it was for me and not just numbers, but also pure examples from daily live of mine.

(Photo: Creative Commons / Stuartpilbrow)

I knew that the course would be challenging as I have family (fiancee and less than 2 years old son) and a job that requires, at the moment, early wake ups. I did not still estimate well enough the impact that the course would have on my daily life. Because I did not want it to take away time from my son, I did not do the course when he was awake (09AM-09PM). When you add the fact that I had to get up to work every morning 0445AM, you will notice that there was not much room for the course.

I was fortunate to go with a bus to work as I could do the assignments there. Then I also used the weekend mornings (got up 05AM, when others woke up 09AM) and during evenings when son had gone sleeping. But this took quite a lot of the time away from me and my fiancee, which I found troublesome.

In the end I was sleeping on the average 4-6 hours per night and it started to eat me inside. Actually now that I had first Monday since the course ended, I overslept 4,5 hours this morning and I thought if my body just decided to take the sleep debt I had kept building.

You might be also thinking why I participated to the course. But I can assure you, that it was still worth it. I had such a strict constraints in my life that it made the course more challenging to me than it did for other people. I still believe though that I managed to make it an experience that gave me and others a lot. I feel more capable as a tester now than I did before the course.

Evolution
Previous part went through the pain I had to go through in order to evolve. This part goes through about how I have evolved as a tester because of the BBST Foundations -course.

First of all, BBST Foundations requires you to participate into thinking practical and difficult software testing problems. Besides that it also requires you to participating into discussions about these practical problems. I noticed through the course that participating into the discussions was perhaps the most fruitful way of learning.

This photo belongs to: Smithsonian Astrophysical Observatory

Other thing that strike me on the course, was that there were so many problems and assignments that seemed in first glance rather simple, but after a moment they grew out to be anything but simple. I thought though that it was a sign of a important skill, noticing things. Specifically noticing problems that are hiding behind assumptions.

I also learned how effective diversity can be for facing problems. When there are people with different backgrounds and thinking, you will receive several interesting varying approaches besides your own. George Dinwiddie once tweeted that

The roof don’t leak because the holes in each layer don’t line up with each other.

This came after we asked about ways of managing confirmation bias. He referred to having people with different backgrounds. I noticed that with my own eyes while discussing about difficult problems during the course. Solutions to problems vary as much as the people who you ask them from vary with their backgrounds. But more importantly the opinions about what actually is the problem vary to the same degree. This is the power of diversity.

The course also had five fundamental topics that serve long time as pilars for my knowledge about testing. These were: Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard. They cover a vast amount of information and I have not yet finished all the material we were either required or recommended during the course. My plan is to do that in the near future. That will take time though as recommended readings included several books.

Summary
I think I could sum up things that I personally learned from the course. I want to though highlight that these learnings are based on my experiences. They might change when time goes on, as I will go through the material again. My learnings are also probably different from other students and even from the learning goals of the course.

Before I list things I learned, I want to mention that I highly recommend the BBST Foundations -course. It will require you to give a lot, but in exhange you will evolve as a tester relatively to the amount of effort you have invested on it.

What I learned from BBST Foundations -course:

• Diversity is a good thing.
• Challenge assumptions.
• Five fundamental topics (Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard) and vast amount of knowledge under them.
• Interaction and discussion are powerful methods for dealing problems and defining what the problem actually is.
• Facing practical testing problems is mandatory for evolvement as a tester.
• Context defines our testing strategy.
• Express myself in a more effective way and think the content of my writings through outline.
• Testing is never perfect. I am never perfect (nor I should aim at perfection). Outcome is a compromise made under the constraints we have.

What we can learn from Russell L. Ackoff

Ilari Henrik Aegerter recently wrote a blog post about great Osamu Tezuka and what we can learn from him. It was an interesting description of a man that resembles of what I consider to be as expert. Key point being regular practice. I want to now make similar post of a man I think deserves one.

Russell Ackoff at Washington University in St. Louis, May 1993 (Creative Commons Attribution-Share Alike 2.5 Generic)

I myself recently saw a Youtube video of Russell L. Ackoff, whom I had not heard of until
then (I want to thank you Bob Marshall for accidentally leading me to Russell L. Ackoff. It was his tweet that mentioned Ackoff.). Now I regret that I have not heard of him before. I immediately watched some more videos of him and ordered a book for my Kindle. I’ve been now reading the book, thinking the things he described in those videos and I wanted to write a blog post that introduces Russell L. Ackoff for others too. In case you have not heard of him before. I will introduce him through few of his f-laws and what I learned from his videos in Youtube (I highly recommend you to watch those videos).

Who is Russell L. Ackoff?

You can read about Russell L. Ackoff from Wikipedia. Specifically his biography and career. I want to though add here a description from the book ‘Systems Thinking for Curious Managers: With 40 New Management f-Laws’. The description is written by his long time friend and business partner Jamshid Gharajedaghi. He says:

Talking about Russ Ackoff is not an easy proposition. His uniqueness and multidimensionality defies conventional wisdom. He was forceful and yet kind; caring but not compromising; fearsome but dependable. For me, he was the epitome of wholeness, bringing complementary opposites into a harmonious whole.

Jamshid also adds later that,

For Russ, choice is at the heart of human development, but choice without competence is meaningless. He exemplified a novel notion in political philosophy that considers colorlessness and the loss of individuality to be as threatening to social sanity as the tyranny of the majority.

Russell L. Ackoff sadly died 29th of October, 2009. That does not mean though that his legacy will not touch our lives now and in the future. As far as I think, it should touch, a lot.

Let us look into some of the ideas he presented via f-laws and his talks.

Systems thinking

Russell L. Ackoff is considered as a pioneer in systems thinking (among others e.g. operations research and management science). Quote that strike me the most on his video that led me writing this post was:

System is not a sum of the behavior of its parts, it’s the product of their interactions.

He was referring to programs of improvement that concentrate on improving the parts separately. According to Ackoff:

If we have system of an improvement, that’s directed at improving the parts taken separately. You can be absolutely sure that the performance of a whole will not be improved.

He uses few examples in his videos and I recommend again that you watch them. I think most of us face in our daily work all kinds of improvement programs that are specifically directed to improving the parts. Like raising the amount of test cases executed, improving the test coverage or perhaps decreasing the time spent on fixing the bugs. You can argue if any of those metrics have any relevance with our work but even more ignorant is focusing on them separately and not thinking on what are the effects on the system as a whole.

Problem solving

Houston, we have a problem.

There is probably not a single person that has not heard this famous phrase (which was originally said as: “Houston, we’ve had a problem”, but was changed for a movie, Apollo 13).

But what is a problem actually? The Wikipedia defines it like this:

A problem is an obstacle, impediment, difficulty or challenge, or any situation that invites resolution; the resolution of which is recognized as a solution or contribution toward a known purpose or goal. A problem implies a desired outcome coupled with an apparent deficiency, doubt or inconsistency that prevents the outcome from taking place.

If we resolve a problem, are we really doing anything to ensure that it won’t happen again? We are actually not looking far enough if we are merely trying to resolve it. Instead if we look from the systems thinking point of view, we should aim at dissolving the problem. Ackoff’s 87. f-law (from the book Systems Thinking for Curious Managers: With 40 New Management f-Laws) states that ‘It is better to dissolve a problem than solve it‘. There is said that:

There are four ways of treating a problem – absolution, resolution, solution, and dissolution – and greatest of these is dissolution.

The description of the law continues on dissolving like this:

To dissolve a problem is to redesign the organisation that has the problem or its environment so the problem is eliminated and cannot reappear. An old Chinese proverb says that giving a hungry man a fish may solve his problem, but it will reoccur. Teaching him how to catch a fish can dissolve his problem.

Before you can absolve, resolve, solve or dissolve anything, it should be noted that problems are based on subjective construct. What problem is to us, is not most often the same as it is to someone else. On the same book 119. f-law says that ‘Problems are not objects of experience but mental constructs extracted from it by analysis.‘. The law is described in more detail like this:

Problems are abstractions. What managers actually experience are messes, which are complex systems of interacting problems. Problems are to messes what atoms are to desks. We experience desks, not the atoms they are made of; we experience messes, not the problems they are made of.

No problem can be solved without affecting others in the system of which it is a part, usually without exacerbating them. A solution to a problem taken separately can create a much more serious problem than the problem solved.

If you want to (dis)solve the problem you need to understand how (dis)solving the problem will affect the system and what the problem really is. Gathering the mental constructs of several people with different mindsets will gain you more understanding of what you are dealing with. Ackoff’s 86. f-law (‘Viewing things differently is not a defect: it is an advantage‘) describes this similar subject stating:

It is only by viewing problems differently and evaluating those differences that the most effective treatments can be found.

Management

The book ‘Systems Thinking for Curious Managers: With 40 New Management f-Laws’ is obviously directed toward managers even though there are a lot of message to everyone else too. According to Ackoff the job of a manager is:

 To manage the interaction of subordinates (s)he has, not to manage their actions.

This sentence was from one of the talks if I remember right. As I understand it, managers should be concentrating on how to make the interactions between the parts of the system work for the purpose of the system itself. Focus should not be solely on what individuals are doing separately.

There is also discussion about metrics, which are talked a lot lately, mainly because they are used to achieve goals that serve no value in terms of the purpose of our existence (organizations). Ackoff’s 51. f-law ‘Managers who don’t know how to measure what they want settle for wanting what they can measure‘ is quite good example of this.

Ackoff also talked a lot about doing the right thing instead of doing things right. This is demonstrated in great way via 109. f-law ‘To managers an ounce of wisdom is worth a pound of understanding‘:

Information, knowledge and understanding enable us to do things right, to be efficient, but wisdom enables us to do the right things, to be effective. Science pursues data, information, knowledge and understanding: what is truth; but the humanities pursue wisdom: what is right.

What next?

I have just dived into the world of Russell L. Ackoff but already see many pieces of information that help me better understand how organizations work and how should we deal problems. Both are essential parts of my career as software testing consultant. As far as I am concentrating on learning more about testing, I also need to gain understanding how my work affects the system as a whole and how I can use that understanding in my advantage. Hopefully someday the knowledge turns into wisdom.

I wish that you will look into the work of Russell L. Ackoff and consider the things he has said and written. Also think of how his legacy affects your work and how you could be the one to make the difference by using that information.

I’ll try to do the same.

Book club with a twist

While walking the path of becoming a great tester, I have noticed that patience is one of those abilities that help you vastly along the way. The downside is that it’s never been one of my strengths.

In sports that I have practiced (rinkball, boxing, ice hockey, etc.) I have mostly lacked the patience on doing my daily rutines and trusting that it will define my success. I have wanted the results as soon as possible and have put equivalent effort on achieving that goal. And it has taken time. Usually a lot of time.

Now I am facing the same situation, but this time it’s not sports that I’m dealing. It’s the profession of software testing. And I don’t have as much time available as I had during those days when I was practicing all those sports. Especially this strikes me when I’m reading books. I’m not the fastest reader so the slow pace of reading the books is getting frustrating.

You can see the portion of the books, that I want to read in near future, from the picture that I took from our office. Besides those there are infinite amount of other interesting books and new ones coming daily basis (especially interested in understanding more of sociology and psychology). Here is a list of some of them (mainly from http://www.ilari.com):

 

• Mindset – Carol Dweck
• The Goal – Eliyahu M. Goldratt
• I want you to cheat – John Seddon
• Tacit & Explicit Knowledge – Harry Collins
• Thinking and Deciding – Jonathan Baron
• The Concept of Mind – Gilbert Ryle
• Exploratory Research in the Social Science – Robert A. Stebbins
• Laws of Seeing – Wolfgang Metzger
• Mind over Machine – Hubert L. Dreyfus & Stuart E. Dreyfus
• Co-active Coaching – Henry & Karen Kimsey-House, Phillip Sandahl
• Dialogue, Skill and Tacit Knowledge – Bo Böranzon, et. al.
• Poke the Box – Seth Godin

Speeding up (without breaking the progression?)

I was trying to figure out a way to speed up the progress of reading the books. I did not want to do this though in the expense of my learning. And so I came up with an idea: book club with a twist.

Like a book club, but everyone reads different books. All the books are new for everyone participating. Idea would be then that everyone reads their books, makes a mind map or some other equivalent way to represent the content of the book (not just chapters) and then we arrange sessions where the people, who have read the book, represent their content to others. And in particular I thought about putting some effort on thinking this from the viewpoint of software testing (e.g. how can I use the information provided in the book for becoming a better tester).

Details are still unclear, but I have now made few plans for attempts to try this. First only me and other tester (@pekkamarjamaki). Also talked with few colleagues of trying this with them too after the summer holidays (that’s one month here in Finland).

I see at least two advantages in this approach. Firstly I need to put more effort on understanding the book I am reading. Besides there is the part where I have to explaining and discussion part which will test my knowledge about the book. Secondly I will gain understanding about books, I have not read, faster than I would have by reading it by my slow pace. On the other hand, this can be a disadvantage. Reading the book by yourself is rarely the same as how someone else has understood it. But I don’t mind. This is an experiment and I will see how it will turn. I will try to though keep in mind the words of Elisabeth Hendrickson: “Don’t confuse speed with progress”

I’ll try to report about the things we learn by trying this book club with a twist. And please share if you have tried something similar.