Roy Osherove is looking for some help on his book on how to explain the ease of changeability of private vs. public methods.
He is looking for an analogous representation on how to better convey this concept to the reader. What I found most amusing and at the same enlightening, where the different analogies that were thought of to explain this context.
When I am speaking to clients I always finding myself coming up with all sorts of clever analogies to explain the problem domain and the impact to the software for certain decisions they might have. For the most part this goes over very smoothly.
When pairing with other developers analogies tend to dissolve rather quickly. I am not sure if it is because we are so analytical that we like to find an outcome for every possible scenario out there or is that we just like to debate. Its probably a little of both.
The way we think is quiet different compared to others, our abstract thought process is geared around the relationship of compositional structure forming some kind of symbiotic state with one another. As the behavior of one object effects another we look for ways to isolate the changes to only a specific stream of concern. This thought process tends to degenerate when an analogy outside the problem domain violates the representation of the model that we have in out minds or if it doesn't compliment it in anyway. Subjectivity does not lend itself either. The fact that most of our craft is subjective astounds me to know end on how we are still able to create such works of art.
I came across and interesting topic concerning analogies called "Shared Structures".
From wikiPedia
According to this view, analogy depends on the mapping or alignment of the elements of source and target. The mapping takes place not only between objects, but also between relations of objects and between relations of relations. The whole mapping yields the assignment of a predicate or a relation to the target.
Which translates to this: Computer applications demand that there are some identical attributes or relations at some level of abstraction. Human analogy does not, or at least not apparently.
Hence why we can't agree on common metaphors to explain anything between us. I use the term "agree" because most of the time we don't, we simply compromise (give in) to the metaphor but we rarely agree to it.
So I was wondering rather then debate about the concept I would like to hear different analogies on various principles and practices surrounding software development. They are all going to different and at the same time brilliant. The goal is to have fun and provide different aids to help convey these principles to other developers.
Who know some of us may be able to bring epiphanies to others.
I will start off the first topic:
Separation of Concern
My car radio and my cars horn both have a shared resource of my cars battery. I can use the two independently without one effecting the other.