dog : cat :: developer :developer :)

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.

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Programming Analogies. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

One Response to dog : cat :: developer :developer :)

  1. Joe Reddy says:

    No Big Design Up Front
    I often explain how nice it would be to build a new house while you lived in it. We could order pizza, sleep on sleeping bags, etc. It helps illustrate the difference between conventional architecture and engineering versus engineering the common business application. I wrote about this on my own blog last summer in an entry called:
    “Don’t put carpet in the kid’s bathroom…unless you want mushrooms…”