I recently finished reading The Power of Pull a book describing how the world-wide adoption of the Internet is changing how we generate value as individuals and in organizations.

The pull that the book talks about is a different kind of pull than what I’ve previously associated with the word. The Power of Pull talks about pull as the means of the individual to access information, attract people of similar interest and achieve common value.

That in working together towards a common goal making individual decisions in the same direction. Generates move value than working in a direction that has been pushed down from a single mind or individual.

It describes how the value of assets keep declining at increasing rates. How its becoming easier and easier to get outrun by a small groups of individuals. It describes the general disruption that the Internet’s increased communication and availability of information is causing.

It doesn’t stop at the individual level however, the book covers how institutions can leverage the power of this process of change. How institutions can change to create environments where individuals can achieve their fullest potential and generate the potential of unlimited learning.

Last the book covers how entire markets can be shaped as pull is being leveraged. Markets can be shaped to provide profit not only to single institutions but for everyone involved in the particular market.

In short the book describes the opportunity that exists right now to collaborate and create something truly fantastic.

I definitely recommend reading this book. It’s excellent food for thoughts.

I recently finished reading Blink. It’s about how we are programmed to make quick decisions. The driving force behind prejudices, but also our inherited ability to make quick and accurate decisions.

It’s funny, the book was mentioned in an episode of “In treatment”, and 60 seconds later I had purchased the book and had it on my Kindle.

Malcolm describes how we all make initial assessments of everything and everyone. The book explains when this ability is not to be trusted and when it is to be trusted.

I found it especially interesting how, for example packaging can change our entire perception of a product. It also explains how we often let our first impression of a person unconsciously affect our interactions with that person.

In essence the book is about decision making, a process that I’ve find to be hard to capture in text. It’s an interesting read and very inspiring, but it is more of a food for thought book than a practically focused guide.

I finished reading Agile Testing, on the recommendation of Mary Poppendick. It’s a thick book, and it took me longer to read than I originally thought it would.

I found it too long, to be honest. It covers both testing and agile principles. For me a better fit would have been if it only focused on testing, implying that I am not the target audience. For the Agile part I would recommend other books on the subject.

The testing parts, however, worked as a muse for my thoughts. It wasn’t long before I was thinking of how I could apply the different aspects mentioned in the book. For instance the book suggests that if the test suite start taking too long to run, it could be split into a quicker suite run each check-in (or my preference each compile) and a longer suite that runs in a build. I realized that most teams I know of would have a hard time splitting their test suites up into quick feedback suites run each time the code compiles and a longer list which run each night. This ties back to some of the problems with TDD where early practitioners risk just producing test after test without considering their value.

Another idea I had while reading the book was that it could be quite easy to produce a test suite for a REST-api using curl and a set of script-files. This suite could easily be automated as well, without need of much programming experience. Then again, it’s not difficult programming either.

The book suggests thinking of different types of tests as features are implemented. Which is good to have as a sort of checklist, and I agree that features should be considered from as many angles as possible for risks or if they can be implemented simpler. However I do not see this as a tester activity or a “programmer” activity. I see it as an obligation for everyone in the team. I do greatly agree with “the power of Three”.

I believe that the book could have been shorter and more concise. Also I could argue that the book isn’t a practical guide, but rather an introduction to agile testing. With this I mean that you shouldn’t expect concrete examples of how to set-up an automated regression test suite. It will however greatly describe the benefits of one and suggest that not every test is suitable for automation (I can see how it’s easy to get carried away with automation).

Despite the fact that I didn’t enjoy the book as much as I had hoped for I would still recommend reading it. However I would recommend readers whom want to focus on the Agile processes to read other books on Agile instead of the chapters discussing processes.

When Mary and Tom Poppendick was in Stockholm a few weeks ago, Mary recommended the Checklist Manifesto by Atul Gawande. And now I finished reading it.

In general it was a good read. Since it’s American it tends not to be very concise, sometimes over elaborating or using constructs of words that could have been shorter. This is normal.

It describes among others how a Checklist somehow can unite the team for the task ahead.

Around chapter 6 it gets really interesting. It’s where it starts discussing what constitutes a good Check-list. Where it divides checklists into two different types: Read-do and do-confirm. To be used in different scenarios. The Read-do is a simple follow this checklist and do the things on it. The do-confirm list is a do some work, then verify that it has been done. In a team verification is done verbally.

It also explains how checklists are used in different industries. What I found interesting was the air-line industry that tests the checklists in flight-simulators. Which begs the question: When did you last execute tests on your software documentation?

The book also describes, among other benefits of checklists, how checklists can increase the communication in the team, by adding communication check-points. One thing that I found missing, was that checklists can help team-members to focus. By having items written down, they don’t have to worry about “not remembering them”, thus freeing up memory space for the task at hand. At least this is the Getting Things Done theory for checklists freeing up focus.

It’s remarkable, the results these checklists demonstrate when used in surgery. And for the question “Would you want the checklist to be used if you were the patient”, my answer is “yes”.