Maciej seems like a super smart and cool dude.  Someone I’d like to hang out with. But I was confused by his post.

It is a graph

Let’s start with his first assertion.

“I. It’s not a graph“

Ok, then uh, what is a graph?

A “graph” in this context refers to a collection of vertices or ‘nodes’and a collection of edges that connect pairs of vertices. A graph may be undirected, meaning that there is no distinction between the two vertices associated with each edge, or its edges may be directed from one vertex to another

More on graphs here.

Directed graphs would include twitter and undirected graphs are Facebook and LinkedIn.  Each of these graphs have nodes (people) and edges (the connections between the people).  By definition, they are graphs.

But Maciej doesn’t actually state, or reason that it isn’t actually a graph – besides what the title of the section claims. What he dives into are all the complexities of defining the edges and thus using the graph. After a bunch of questions and complex cases, he states “You can call this nitpicking, but this stuff matters! “.  And I agree, it does matter.  But so what, just because something isn’t perfect doesn’t make it not useful.  Heck, Twitter is quite imperfect, but millions of people seem to think it’s useful.

Let’s see, what else does he say in this section?

But it only takes five minutes of reading the existing standards to see that they’re completely inadequate

Inadequate for what? Oh wait, right before that he states

This is supposed to be a canonical representation of human relationships.

Ah, now we’re getting somewhere.  The Canonical Representation of Human Relationships. Uh huh.  Good luck with that. This definition of what these social graphs or any social graph is attempting to do is bizarre.  When I myself can’t even put into words my relationship with other people, how are we supposed to have a real-time canonical representation of human relationships?  We’re not.  That goal is not a serious goal.  It is not possible.

It’s like he doesn’t understand making a useful model and making an “accurate” model.  All models are wrong, right?  Who cares about “canonical” as long as a model is useful.

And here’s another jewel

My friend from ten years ago has the same relationship to me as the friend I dined with yesterday. You’re left with forcing people (or their software) to maintain lists like ‘Recent Contacts’because there is no place in the model to fit this information.

Yeah, we couldn’t possibly figure out a way to decay a relationship based on activity.  What?!  Just because current implementations are dumb as rocks fairly basic, doesn’t mean future graphs won’t be improved (and obviously he knows this).  Facebook, Twitter, and LinkedIn all have data to continually define the edge(s) between nodes.  Without the person “maintaining a list”, as Maciej claims.

I’m glad he brings up the concept of the Uncanny Valley. It’s a useful concept for software developers and UX folks.  In this context, it appears what he’s implying is if these graph systems attempt to “guess” more personal data about us, the “creepier it becomes.”  Sure, this has been the case with marketing forever.  Nothing has changed substantively with social graphs web things.

He ends this section with

I think finding an adequate data model for the totality of interpersonal connections is an AI-hard problem

Total agreement on this.  But again, these social graphs are graphs.  They are useful graphs with deficiencies.

It is Social

II. It’s Not Social

Note: I have no idea what the word “unsocial” means. Since social means living in a community, with others, and anti-social appears to mean averse to organized society.  I’ll assume “not social” means anti-social.

Maciej starts by discussing a particular implementation (FOAF) and its deficiencies.  No problems there.  Anyone who has looked into FOAF quickly realizes the implementation is problematic.

Before diving into some examples

Your best friend from high school surfaces and sends a friend request. Do you just click accept, or do you send a little message? Or do you ignore him because you don’t want to deal with the awkward situation?

Um, that sounds social to me.  If the friend were to call on the phone, would that not be social?  Why would a phone call be different than a freind request? What makes the friend request not social?  Because it is on Facebook?  Or, what is Maciej’s point?  I’m assuming, based on the section title, that he was going to point out the ways the graph web thing isn’t social.

Continuing on

Leaving aside the technical issues of how to implemented, how does cutting ties actually work socially? Is there any way to be discreet, for example, or have connections naturally degrade over time? In real life, all relationships fade naturally if you don’t maintain them, but right now social networks preserve ties in amber until we explicitly break them.

Let’s break this down.  He states “In real life, all relationships fade naturally if you don’t maintain them“.  Agreed.  And then “but right now social networks preserve ties in amber” (emphasis mine).  This is not true.  The feed I see in Facebook is defined by how I interact with my connections.  The edges of the graph web thing are continually adjusted. They are not “preserved in amber”.

If one were to focus on the binary bit of whether someone is still technically my “friend” on Facebook, while at the same time ignoring that I never ever see that persons’s posts, sure, they will incorrectly claim the relationship is preserved in amber.  (Yes, there can be more than one edge between nodes.)

Twitter made the excellent choice of directional relationships out of the gate, so this is less important.  It’s still important and I suspect they’re working on degredation right now.  Heck, it might even be implemented for all I know.

Continuing…

The social graph wants to turn us back into third graders

Well, I suppose that’s possible, but I personally don’t see it.  Oh wait, here’s why he thinks that

….laboriously spelling out just who is our fifth-best-friend

No.  On twitter, we interact with others, just like in real life.  We’re not “laboriously” listing or codifying or other “third grade” activities.  We’re being social and that act of being social is stored, used to improve the graph model, and thus used to improve our ability to interact with others.  The cycle repeats.  It seems Maciej is overly focused on the following/followers and needs to focus a bit more on retweets and mentions.  Which are social acts.

He then veers into the woods with ramblings such as

apps whose first act is to suction down our contact list and spam our various accounts

Yeah, google has an api and apps can get me to spam my contacts.  So what?  Yes, there are bad people out in the world and a sucker born every day.  Not sure how this is germane.

Continuing

In other domains, a big graph would be good for recommendations, but friendship is not transitive. There’s just no way to tell if you’ll get along with someone in my social circle, no matter how many friends we have in common.

There’s no way for who to tell?  I mean, people recommend friends and contacts all the time in the “real world”, right?  And that can’t possibly be done by software?  Recommending friends in the real world seems social to me.  Call me crazy.

About here in the article, I’m still trying to figure out his perspective, when finally we get this bit

Social networks exist to sell you crap

Some people would say businesses exist to sell you crap.  Who, the fuck, cares.  Seriously, this sounds like one of my rants. Yes, Apple is continually trying to sell me crap. They spend millions on ads, they use beautiful packaging, and they make amazing products.  Those sons of bitches.

Oh wait, they’ve also made parts of my work life amazingly better.  I’m old enough to remember lugging around a compaq portable with a plasma screen.  Too bad these companies are continually trying to sell me crap.

So yeah, companies use marketing to influence our decisions.   AND, they collect data to make better decisions.  That’s crazy!!

But guess what, they provide us with value.  Like, for example, the tweet (retweeted by others) that led me to write this blog post.

Continuing

We’re used to talking about how disturbing this in the context of privacy, but it’s worth pointing out how weirdly unsocial it is, too. How are you supposed to feel at home when you know a place is full of one-way mirrors?

Granted, privacy is a huge issue. But guess what, life itself is not private. What you say and do is often in front of other people.  Even when it isn’t, it is sometimes shared with others after the fact.  Who hasn’t had this happen?  That sounds like real life to me, that sounds social to me. Not always great, but certainly social.

Ok, we’re getting close, and I’m growing tired

We have a name for the kind of person who collects a detailed, permanent dossier on everyone they interact with, with the intent of using it to manipulate others for personal advantage – we call that person a sociopath

Or, a recruiter.  Heh.

It’s interesting to me that he doesn’t mention the Twitter.  I guess they’re not mining data on what we tweet or retweet? My other guess is that he just doesn’t like Facebook.

But really, this is all about privacy.  It isn’t about whether these sites are or are not social.

Part III

Maciej finally gets to the part of what needs to be done to make “awesome” online communities

Give people something cool to do and a way to talk to each other, moderate a little bit, and your job is done.

hmmm, that sounds a bit like Facebook.  In fact, a lot like Facebook.  With hundreds of millions of users, I would guess many people think of it as somewhat awesome. Or at least a bit useful.

But then he states

Now tell me one bit of original culture that’s ever come out of Facebook.

Lost me.  What the fuck is “original culture” and why is this used as a challenge for Facebook?  Perhaps Maciej does not like Facebook. (Wael Ghonim thinks otherwise.)

He ends with

and that our kids will think we were complete rubes for ever having thrown a sheep or clicked a +1 button. It’s just a matter of waiting things out, and leaving ourselves enough freedom to find some interesting, organic, and human ways to bring our social lives online.

Agreed.  I’m totally against sheep throwing.  And plus-oneing. And I can’t wait for the Google+ and Facebook replacements.  I contributed to the Diaspora project and hope an open source social thing wins out soon.

But let’s get real.  Just because we have a significant distaste for the actions of these large companies, does not make what they provide “unsocial” nor are they not graphs, nor are they not useful.  The world is likely (net) better off than it was before Twitter, Facebook, and Google+.

Notes:

* Facebook is not a pure undirected graph.

* Me thinks Maciej titled his article for maximum social graph sharing, not to make the 2 listed points. It worked, it was shared. Well played sir!

* Maciej seems like a pretty cool dude.  This is not intended as a personal attack, just needed to add some balance.

* At imby, we plan to have a unidirectional edge with multiple edges between nodes (based on tags) that decay.

* There is a lot to be said about the horrible practices of some businesses as it relates to privacy and control of personal data, but that was not the subject here.

I’m a member of several software related meetups in Madison.  There is the very active Ruby group Mad-Railers, which meets most every month and Twilio-Madness, a slightly less active Twilio related group.  My idea was based on mobile phone communication, so I sent this email to the Twilio-Madness group.

Hey Twilio people!

Considering all the energy in WI lately and the fact we have a statewide election April 5, I thought it would be cool to build a Twilio powered app that helps people participate in the most important democratic process.

The app I’d like to build will use data from the GAB to provide information and instructions to people interested in voting.  An example of searching that data is here:
https://vpa.wi.gov/VoterSearchScreen.aspx?Language=en-us

The goal of the app would be to make WI a beacon in the country in regards to voter participation, especially young people who are most capable of using SMS, touchtone, web.

I’m starting this app tomorrow night at Horizon Coworking (Inside the Murfie offices) and would like any help from anyone who wishes to join either then, or over the next week.

- Philip

Several people responded they were interested in helping out and the group of people had a diverse skillset – community organizing types, a design capable entrepreneur, and a few programmers.  It was go time.

In a few days of intense working, we banged out the app, came up with a name, connected with partner organizations,  printed marketing posters, designed a logo, and launched VoteSimple in time for the spring election.

It was a cool process and I was proud of what the group accomplished in such a short time.  We have long term plans to improve the app with an SMS based question answering system (think Stack Overflow) for people confused by the recent voter ID laws.  We also are part way into developing a Facebook component to help active voters influence and educate their peers in Wisconsin – all with the goal to increase turnout.  (We’re a non-partisan group and turnout is our goal.)

I’d like to thank the following people for helping in this effort.

• Philip Crawford
• Mark McEahern
• Matt Clark
• Preston Austin
• Steve Faulkner
• Lucas Dailey
• Matt Wheeler
• Erik Paulson
• Greg Tracy
• Maurice Cheeks

If you are a rubyist or an expert using Twilio and would like to help, let me know as we’re all quite busy and any extra help will help.

Think about a normal situation for a business wanting to update their web site.  The goal is not to have a new website, that is simply the means to an end.  The goal is to improve their business, which for most businesses is measured in terms of more customers, more leads, more sales, more users, or similar measures.

The goals are related to making more money.

So the business owner (or manager) hires a web design firm to “fix” the web site.

Are the goals of the firm aligned with the person who hires them?

No.

And this is one of the trickiest parts of purchasing design services.

Goals of Designers

Designers have different goals than your business. The reason is designers are managing their own business.  Even if the designer works for the firm, they have a career and their future is based on the visual portfolio they can show to future potential customers and employers. On it’s own, this is not highly problematic.

Good design for you should translate into a better portfolio for the designer.  However, most purchasers of programming and design services are unsophisticated and designers have learned this.  Designers have learned to produce designs that make statements, rather than designs that enable great user experience.  Also, due to the short lifetime of designs on the web, designers also know they won’t be able to simply point a future employer or customer at the site in order to experience the great design and user experience – as the site might no longer be online.

Designers are often judged based on their creativity – rightly so – however this systemically pushes design away from doing the same old boring things that work, toward the unique and noteworthy.  As many user experience and usability professionals have pointed out over the past decade, your users spend most of their time on other sites and very little time on your site, so making them learn a new way of doing things just so your site can be “unique” is very problematic.

In total, these issues create motivations for designers to create work that is overly designed and too unique for the majority of design purchasers.

What You Can Do

In my experience, there are three (related) techniques you can use when working with designers.

1. Ask them to explicitly list the design and UX patterns they are utilizing in the design as well as the corresponding research that supports those patterns.  These should be testable ideas, not just opinions about what looks good.  Remember, this isn’t art we’re creating, it is design the helps your users/customers do what you want them to do – sign up, place an order, read more, etc.
2. Have them help you setup A/B testing of several home page designs. (Or designs of whichever part of your site is being redesigned.)  This is one of the processes utilized to determine the best practice design patterns utilized in the above point.
3. Explicitly state your fear of having a design that is more focused on their portfolio rather than your business objectives.  I’m serious here, they need to hear this.

Collectively, these techniques can help you ensure better alignment of your goals and the goals of the designer.  It’s not easy, as can be seen in many of the tragic, over designs on the web.

This has happened to me several times over the past few weeks.  As someone who has spent several years in the email marketing business, I’m always a bit curious (and irritated) and I often peek under the covers to view the list of subscribers.

Last year I received a broadcast email from CCAP, the state agency that sells the data (a SOAP interface) we use for ForeclosureAlarm.com. The email included all their other customers in the “to:” field.  It was very interesting to see a list of other companies that purchase that data.  Very interesting.

Don’t get me wrong, I get a pretty upset when this happens.  Not this upset,

but I’m not a happy camper that my email address has been shared with hundreds of people I don’t know. Sometimes I’ll even reply back to the sender letting them know about this magical thing called a bcc.

This gets me to the google and their gmail service.  You see, gmail already does some fancy things with their service.  For example, if you say something in the email about an attachment, but you don’t actually attach a file, they tell you.  Pretty slick and a very nice feature to keep people from embarrassment.

Gmail should be checking emails that include a bunch (dozens or more?) addresses in the cc: or to: fields and then provide a friendly note to the sender, with maybe a link to a knowledge base article, that maybe the sender wants to actually put all those addresses in the bcc: field and why. It would help protect their customers from abusing their friends email address and it would make gmail better.  A win win.

There you go Google, keep track of improper use of the “to:” field by your users and it’ll help keep me from feeling like this.

Programming is more about Design than Typing

Over the years I’ve noticed a difference between great programmers and average ones.

Average programmers are often seen typing.

Great programmers are often seen staring at code.

The reason, it seems, is because great programmers are thinking bigger.  They’re thinking about dryness, code consolidation, reuse, simplicity, using the existing framework, and a lot of other things than the specific tracker task they’ve been assigned.  Average programmers focus more on simply creating the code and tests for that task.  As a percentage of their work, average programmers type more.

Thus, focusing on the typing aspect of programming is biased toward the mediocre. It is the “small lever” within software development.  The big lever, the one that effects the long term cost of software development and maintenance is design.  And design comes from thinking.

Design (and thinking) is improved by dialogue

The real power of pair programming comes about due to the dialogue between the developers.  In order to present a design idea, the developer needs to put his/her idea into words and that process alone is often very valuable.  It is very easy to have an idea about how to solve something, yet gloss over some of the details or complex issues.  By taking a vague design thought and putting it into words, the person with the idea is actually learning about his/her idea. Obviously,  this process of verbalizing a design is usually missing when working solo and often a developer will simply head out in a “direction” confident they will figure out the details as they proceed.  With pair programming, a pair usually doesn’t allow this.

This verbalizing is inherently a good thought process.  The gaps in your thinking are exposed.

Along with discussing the solution design, the developer also likely will state their assumptions about why they think something should be done.  The assumptions could be about risks, costs, testability, etc.  And again, that dialogue between developers leads to further knowledge transfer and understanding.

Here’s a quote from The Costs and Benefits of Pair Programming

We often came up with different ideas about how the design should go and the result of arguing over which one was better often led to a truly superior hybrid design.

One last note about design.  I have found that pair programming tends to keep developers near the minimum of the cost curve (written about in Line Count and Maintenance Cost) instead of the arcane and wordy areas of the graph.

To sum it up, forget about all the nitpicky stuff in pair programming, that is not the long lever. It’s about quality and maintainability of software, but that will only happen if the developers are truly pair programming and not simply sitting together at the same keyboard.  But that’s a different post.

They aren’t.

I’ve been implementing both lean and agile processes since the early 90′s.  The concepts aren’t new, but they are relatively new to the software development world.  I’ve read about and taught TPS, SMED, and many other parts of lean production as well as many of the concepts used in agile manufacturing.  Their application to software is incredibly similar.

Lean is an inward focus.

Lean is a measure of the entity separate from its customers and historically is a measurement of waste.  Reduce waste and you are more lean.  The Toyota Production System (one of the oldest lean manufacturing system) has a constant focus on the elimination of waste.

Lean is loved by many executives because it conforms to the “world as machine” view. Taylorism, and it’s descendants such as business process re-engineering, have viewed the business entity and its processes (and the larger scale systems the organization exists within) from a mindset of planning and control – again, a world view most managers seem to prefer.

Agile is an outward focus.

Agile is dirty, organic, unknowable, unplannable, which makes managers and executives uncomfortable.

To be Agile, you do need to be somewhat lean, but the leanness is FOR agility, not the goal.  The difference is important.

Agile is measured not with internal measurements, but as a measure of how well the entity responds to changes in the external environment.  Waste and leanness are not the goal and as Eli Goldrat has shown time and time again, being more lean in the wrong places can make you much, much less agile.

It’s important to understand why agility has become so important over the last several decades.  It’s due to the continual shortening of product life cycles, customer order cycles, and the increase of product competition due to information exchange.  No longer can you release a product once every few years.  Even the idea of software versions is becoming somewhat obsolete (what “version” is the google search engine?).

Which to focus on?

I spend most of my time in the web world where agility, the ability to adapt to a changing competitive landscape, is the number one competitive advantage for a software firm.

Agility is customer focused and these days the customer is king.

So I choose agility over leanness every day.  It isn’t even close.

Over the past few years I’ve been working a lot more with Ruby and the Rails framework.  I’m not sure why, but there seems to be a social norm in the community of impressing others by consolidating code to as few lines as possible (often just one) with the (mistaken) belief that the code is better.  And that sometimes makes me feel like this.

Those programmers that create some of this amazing, yet arcane code are usually some of the best programmers I’ve ever worked with.

The problem is that they’re often misguided in this pursuit of brevity.

The relationship is probably not linear and there is likely not only diminishing marginal returns (which are almost always inescapable), but there is likely a negative relationship at some point.  The reason is that although the advanced programmer can handle the complexity of the “arcane” lines of code, those that maintain code are often not the ones writing it – specifically and also in skill level.  The more arcane the code is, the more time it will take those maintaining the code to understand it.

The relationship is probably like this graph.

It’s been my experience that good programmers do not need to be reminded of writing DRY and concise code.  Quite the opposite.  As a project manager, I believe it is necessary to inform and remind those great programmers of the potential for increasing costs due to an overemphasis on the reduction of lines of code.  Strange but true.

One day I wrote down a list of 25 thoughts on risk management and testing.  Eventually I’ll weave these ideas into articles, but for now, just a <ul>

* Everyone contributes risks

* No risk exists without probability and impact

* No impact is infinite

* All impacts are measurable

* Risks drive level of design

* Risks drive test plans

* Testing directly affects design

* TDD is not 100%. The decision heuristic is risk.

* Exploratory testing approach is publicly known so customers and decision makers can know what has been tested.

* The word “requirements” promotes simplistic thinking. We develop features up until the point at which a person or team decides to deploy. Some features are never implemented. Listing as requirements makes people think in binary mode instead of order of importance to the organization.

* Measure progress based on running features tested. Compare sum of the weights completed with the total targeted feature set weight.

* Features all have a “weight” relative to other features within the same project.

* A feature without a running test is analogous to “works on my computer.”

* In all projects there is a point at which the set of claims tests are a more accurate statement of what the software does than the list of features (or requirements for you old schoolers.)

* Some features like “easy to learn” are not testable claims. Are they?

* A goal of gathering and writing features is to have them written as claims.

* The best types of claims have inputs and outputs because there is less interpretation in the process from documenting the feature to writing the code and tests.

* Tests are either named or described in a way that relates them to a feature.

* The build process generates a list of all test results for a project. The tests for a project can exist in multiple places (web app, shared component, project specific component)

* Risks have the greatest focus of the project team. Not the “requirements” document. It is a fallacy that software development is about creating a 100% complete list of requirements and then coding to that list.

* Risks are the most managed “thing.” Later in the development process, issues become the primary management tool.

* A project has a list of tests and you are able to click a link to view the actual source code of the test.

* Each test has a history of pass/fail.

* When a developer completes an issue, they add a comment in the issue message that can be run by the reactor and will send a result to the nosy list.

* A daily email is sent of verification results. Project name -> className.testName of failures with link.

For many software teams the requirements document is the king of documents.

You know the routine. The software team works with the customer (or customer proxy) to put together a “complete” list of “requirements”. Once that is done, the team writes the software implementing the requirements and voila! the project is done.

Or maybe not.

Every software project I’ve ever been on has involved scope management. This is a process of determining if a requirement is truly a requirement for right now and whether it could be delayed until part of a future version or release. This is performed not only when “requirements” are being first developed, but also during development/testing/deployment in an effort to meet a project timeline constraint.

Words Matter

In the Agile development world, “requirements” is sometimes replaced with “features”.  This is a very important change, mostly related to the meaning of words and cognitive dissonance.

Think about it.  “Requirement” is based on the word “require” – something compulsory or necessary by rule. For someone to agree to postpone a “requirement”, you are basically asking them to admit it wasn’t actually required in the first place – thus, it wasn’t a “real” requirement.  And therein lies the problem…

Asking someone to postpone a “requirement” is asking them to admit a mistake.

This points to the beauty of using the word “feature” when describing the software desired.  Features connote desires.  And it is OK for customers to desire pretty much everything.  “You want features, load me up!”  Throw features on the deck, list them like crazy.  Pile them on, as project managers, we’re not afraid of hundreds or thousands of features.  Knock yourself out – as long as they are prioritized.

Once we start developing, we can then start having conversations such as:

• Do we have enough features to deploy?
• Would you like to change the priorities of the features you’ve listed?
• Any new features?”

Those are much, much easier conversations to have and project decisions will be made much quicker without the debates about whether a “requirement” is actually a requirement.

In what appears to be some form of risk management strategy, these login forms introduce a different risk to the websites that use the default behaviors – in RoR sites, this is often either AuthLogic or RestfulAuthentication.

Both are broken in a big way.

First, the bug.  And you might not even recognize it is a bug because the behaviour is so wide spread, so ingrained, and so “sensible”.

On almost every login form, if I submit either the wrong username OR the wrong password.  I get the same error message.  Usually it’ll be something brief like the following.

Notice the very important word in this message.  OR.  Because the error message is the same if I enter the wrong user name OR the wrong password, I don’t know which piece of data I entered incorrectly.

I’m guessing virtually everyone reading this is now thinking “well yeah, if you tell them which piece is wrong, someone can keep guessing until they get it right.”

Before we get into that, what are the risks being mitigated in this process?  You don’t want someone to hack into one of your user’s accounts, right?

Right.

But what else?  How about the risk that someone, a new user, comes back to your site and has forgotten which password they are using?  Maybe you forced them to use some complex password.  Maybe not.  In any case, maybe they want to use your site, but it isn’t really that important.  As web app builders, we’re constantly thinking about lowering the barriers to join and begin using a web application, right? Why would we add a barrier here.  It is possible that a user with difficulties signing in might just leave.  Never to come back.  Never to pay you for your service.

All because you were not kind in telling him/her why the credentials they gave on login didn’t work.

So, that’s a risk.  And for a startup, this is a significant risk.  You need every new user you can get.  Especially those people that have taken the time to actually create an account.

But let’s get back to the “common sense” reason for not telling the user more about why their credentials didn’t work.

You may notice on the signin form above, that link to “Forgot“.  If you click that link and enter a user name (email address in this case), the system will almost always tell you if that user name exists.  Using the above site, it’ll look like this.

So, lemme just repeat the problem.

Login forms almost never tell you if your user name is wrong

Compared with

Forgot password forms almost always tell you if your user name is wrong

So let’s get back to that risk that is supposedly being mitigated by not telling the form submitter what piece of data is wrong.  We’re trying to keep people from guessing user names, right?  And yet we provide a form for doing exactly that!

The risk is not mitigated in the slightest by the error message.  Not one bit.

Now, I’m not going to go into how this process should be done.  For two reasons.  One, I’m out of time for writing this morning.  And Two, because I want people to disagree with me so I can understand their thought process.  It is possible I’m missing something here.  Unlikely, but possible.