In The Right Thing, James Hague discusses the challenges of selecting good libraries to support your application. In James' example it's a Perl module that turns out to be unmaintained and eventually falls victim to a security issue.

I read James' article a couple of times. On the first read, I took it as a comment on the peril of replacing working code with a third-party library. On the second, I took it as a comment on dependencies and over generalization.

I sympathize with James. He doesn't go into detail on his program but it's hard not to rationalize using a library when one is available. There is the problem of replacing working code with a library.

His comments echo concerns in my own product on the introduction of libraries. The product I work on overuses (some say, abuses) an application framework to the detriment of the product. In response, some team members are suggesting other libraries with simpler APIs but supporting similar functionality.

On the surface, adding libraries is reasonable.

What bothers me is that agreement means I have two libraries with similar functionality but different APIs. There differences introduce costs--additional tests, learning curve, different failures modes and security issues. It introduces the question of which library to use going forward.

There is no easy answer. A good answer requires understanding the trade-offs involved.

• I want a consistent product architecture.
• I want to avoid arbitrary complexity. 
• I need to be pragmatic--the pragmatic demands guidelines. For example, replacing the old library with the new one or using the new one whenever it is sufficient for the task at hand.

The change in perspective provided by the second read was profound. I view James' comments as a warning to evaluate dependencies before accepting them. Caveat emptor, if you will.

So what do you look for in your dependencies?

• actively maintained
• recent release
• good platform support
• good reputation within the community
• active user community
• large user community
• meaningful tests 
• documentation

James provides several links to support his article. In one link I was introduced to Huffmanization. I wasn't aware there was a term for making your most common function names meaningfully short.

In Whispers and Cries Mark Bernstein discusses the dangers of misinformation and how blindly accepting information--the unwillingness to challenge the status quo leads to problems. I share my experience with misinformation in Product Backlogs: Not Just Stories! when I explored statements made by Bertrand Meyer on user stories and Agile practices. Because of that exploration I corrected an error in my thinking on Scrum.

The insight Mark provides is to build a better network for your questions and to allow yourself to make mistakes. He points out that most software developers work in caves or enclaves. Those in caves use the tools and techniques they already know and only acquire new knowledge as required by circumstance. Those in enclaves use commonly accepted practices within those enclaves and that wisdom-formation in enclaves is often erratic.

What prompted Mark's article appears to be a discussion in The Dangers of Misinformation. There is advice in that article on how to share information and avoid spreading misinformation.

The situation in Mark's article and the one he references both identify a form of bias. Misinformation, when accepted by an enclave or by large numbers of people is a form of social proof. I suspect that those of us working in caves suffer from social loafing.

The error identified in my thinking on Scrum was introduced through social proof: when I learned Scrum the people teaching me insisted on user stories to manage my product backlog. I asked for and obtained references. Those references reenforced the use of user stories and I accepted it as correct.

Fortunately, there were problems in our implementation of Scrum. These problems prompted me to do my own research. That research led me to the Scrum Guide. Unfortunately, my review of the Scrum Guide didn't reveal my error in thinking on user stories.

Fortunately, I enjoy Bertrand Meyer's work so I purchased "Agile! The Good, the Hype and the Ugly". Ironically, it wasn't his position on user stories that identified my error. It was his position on how user stories were inadequate for some types of systems that caused me to delve deeper.

I had been troubled by user stories when I first encountered them. As I gained experience with them, nothing pointed to any inadequacy. They were just new and different. Meyer's comments on additive and multiplicative complexity caused me to review why user stories had worked for me. It was that investigation that led to the realization that I had misunderstood how to populate the product backlog.

My misunderstanding about user stories and Scrum lasted four years. During that time my defences against social proof failed because the biases of the people teaching me Scrum and their own research reenforced what I was taught. My own experience with user stories only confirmed these biases and further entrenched these ideas.

Doing your own research is important and that using original sources for that research is critical. In exploring Meyer's position on user stories I reviewed both the OOPSLA 95 paper that introduced Scrum to the work and the Scrum Guide to confirm part of what Meyer's said about user stories.

The only activities that led to identifying my error was my desire to learn more about Agile methods. Meyer's work provides an invaluable resource simply because of its contrarian views--whether you agree with them or not. In my case, the urge to explore and understand why he reach conclusions that contradicted my own experience were critical to my new position on user stories and the product backlog.

I wanted to call attention to What Can You Put in a Refrigerator? a blog post by James Hague. If you have struggled with the notion of audience for a specification James' post on specifying refrigerator content does an great job of drawing out this challenge. The article is great for both its humour and the point it makes.

In "Feature-Based Development: The Lasagne and the Linguini", Bertrand Meyer raises the spectre of multiplicative complexity and the failure of the user story to address this complexity. In Meyer's view, a user story is too simple to manage requirements except for certain types of systems. User stories become unwieldy if there are feature-based interactions to manage.

The Scrum Guide describes the Product Backlog as providing a single list of requirements for a product. The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Backlog items have a description, order, estimate and value.

The Product Backlog doesn't require stories explicitly and acknowledge the existence of other types of requirements. Meyer's book goes on to mention that user stories are the preferred method for expressing requirements within Agile methods. It's obvious how Meyer's arrived that this conclusion for XP but how could he possibly include Scrum in his assessment?

A quick look at Scrum Alliance shows that the Product Backlog should be written using user stories might be easy to come by. For example: Product Backlog and Give Life to Your Product Backlog both discuss how to manage user stories in the Product Backlog.  (In the defence of Scrum Alliance, Core Scrum uses language similar to the Scrum Guide to describe the Product Backlog.)

Curiously, Mike Cohn's Scrum Product Backlog perpetuates the notion that the Product Backlog is populated with user stories. Cohn's article references examples from Scrum Alliance. His article on the Advantages of User Stories for Requirements contains arguments in favour of user stories over traditional requirements.

The SCRUM Development Process was presented at OOPSLA 95 by Ken Schwaber. It discusses a control on the Scrum methodology called the Backlog. The Backlog contains:

Backlog: Product functionality requirements that are not adequately addressed by the current product release. Bugs, defects, customer requested enhancements, competitive product functionality, competitive edge functionality, and technology upgrades are backlog items.

If the Scrum Guide and SCRUM Development Process present similar language for the purpose and content of the (Product) Backlog how have user stories become the favoured method for capturing requirements?

In "Agile! The Good, the Hype and the Ugly", Meyers fingers Test First as the culprit. Test First and the notion that tests are a suitable replacement for requirements and specifications.

Curiously, the Scrum Guide is again virtually silent on testing. It states that development teams have a responsibility for testing and that this responsibility requires that each increment be fully tested to ensure that all increments work together. (An Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.)

Likewise, the SCRUM Development Process requires testing during development. It does not require a specific approach to testing.

In all, I agree with Meyer's position on user stories and XP.  He is correct in applying this reasoning to Scrum as well, although I don't agree that the intent of Scrum was for requirements to be managed only with user stories and Test First.

User stories and test first are artifacts applied to the Scrum framework. They are not a requirement of Scrum itself. Their use is imposed upon the framework by the organization implementing Scrum. That's an important difference.

I have two WiFi networks. My Sonos is on one network. Everything else is on the other. Occasionally, my Sonos Controller for Mac reports that it does not have permissions to access a music library located on my MacBook Pro. This occurs when adjusting my Music Library Settings in the Controller.

I corrected this by moving the the MackBook hosting the music library to the same WiFi network used by the Sonos.

The music library is still accessible after moving the MacBook back to the other network and restarting the Sonos Controller. This implies that the permissions issue is confined to the initial set up the music library in the Controller.

A better solution is to put all Sonos' and the MacBook on the same network.