Untangling the Knot

[Symbology]

Forget about what the "perfect" approach is, realize its all about communications, alignment of goals and getting people to understand what they're really getting for their money.

 

By the way Buffy... could you give a concrete example or two of this? For example a case where you worded it the right way so that they "got it".

 

Thanks,

Symbology

[Symbology]

Here are a few thoughts from today's discussion between Pyro and myself:

 

The reason why we can untangle knots in algebra is because we have the equal sign to move things across.

• If something gets in the way of what we are working on, we just move it to the other side of the equation.
  
• Once something is isolated we can perform transformations on it.
  

 

Paraphrasing an earlier point made by Pyro: The difference between a genius and a wizard is that once a genius explains what he did, everyone goes "oohhh, I get it!" After a Wizard explains what he did, everyone is still left in amazement.

 

To my observations, illusionists are very good at hiding things "on the other side" just like we do on the other side of the equal sign in algebra. Just consider the equal sign the magic hat or the curtain. Similarly in computer science we use "tricks" like hashing to make a data entry disappear into the ether and reappear at will.

 

By getting obstructions out of the way, we can focus on the task at hand until we have solved that particular tangle or issue.

 

Following that metaphor relative to the start of this discussion, I have seen managers perform magic in getting obstacles out of the way so that the programmers can focus on the issue at hand.

 

To my experience the main way I have been able to accomplish it myself has been with documentation (as Pyro gave in his excellent list), and coding frameworks. The frameworks can hold partial or incomplete aspects in place, until such time as they can be completed or replaced with solid components.

 

I think it is these frameworks (often in the form of meta data about the original application) that may be the main tools which can be used to untangle the knots. Per Pyro's link to Layers of Abstraction: If a rule works at one layer, it is not normally going to work at another layer. I would say this is generally correct. But using functions we can usually abstract a collection of "cattle" and rewrite the function for "livestock" instead using proper meta data.

 

The cattle owners tend to get upset when I tell them I have a module that can be used for both cattle, sheep, and goats. But if I am just counting heads of livestock and running them into a chute, it's the same process. I just point it at a herd and let 'er rip! (By the way I would equate that chute with the equal sign metaphor. Using it we can isolate one animal at a time to transform them as needed.)

[Symbology]

An observation I was describing in my discussion with PyroTex today is one that comes from my experience. When I have to assimilate multiple functions which I observe are all serving a similar purpose (insert appropriate Borg reference here) :

• My first abstraction on a given case tends to be the "Prototype". It is very rough.
  
• Testing this prototype and adjusting it to fit the second concrete example is usually the toughest part, and is likely to introduce the most number of errors.
  
• After testing and applying the abstract code to the third concrete example, the code tends to be much more robust and ready to take on the 4th through Nth cases. Basically the skids have been greased at that point.
  

 

This falls in line with what I have observed of releases of major software such as Windows 3.0, 3.1 (yechth!), and 3.11

OS/2 v1 (as if), v2 (God help us!), and v3

and basically all other major software and drivers. The copy you want is always the 3rd version.

 

 

"Third time's a charm"

[Buffy]

Forget about what the "perfect" approach is, realize its all about communications, alignment of goals and getting people to understand what they're really getting for their money.

By the way Buffy... could you give a concrete example or two of this? For example a case where you worded it the right way so that they "got it".

The first thing you need to do to convince someone of anything, is to figure out what they want. Not what they *need* or even if something is good for them then its good for other people too: heck doing so may set you up for a trap! Thus:

The cattle owners tend to get upset when I tell them I have a module that can be used for both cattle, sheep, and goats. But if I am just counting heads of livestock and running them into a chute, it's the same process. I just point it at a herd and let 'er rip!

YOU think they're the same, but that remark just *proved* to the cattle owner that you don't know a lariat from a cow pattie. Now he won't listen to a word you say.

 

Doesn't matter that you're right, its all about convincing your subject that you "feel his pain." One of the odd-ball ways to do that is to make sure that you realize that *his* problem is unique, and requires a special understanding that only fellow cattle lovers can appreciate. De-adversarialize it. Take them out for a beer. :)

 

Now the problem in this example is that you know that the chute won't take your head counter gizmo without some modifications. That will take time that looks to the inexpert as "unnecessary" and its "new and unfamiliar" and therefore generates instant resistance. There are a couple of approaches, all of which should be taken to certain extents:

• Check your gizmo. It may be possible to make a quick change to it so that the changes required to the chute aren't so necessary. In most cases since you *know* the gizmo is "perfect" you'll forget to question whether or not in the *real* world if it really is. Shame on you if you don't. Makes life much easier. Make that gizmo's attachment rod a little bit better balanced so you can use the flimsier top rail on the chute. Then comes the important part: *brag* about it to your customer, avoiding any technical talk, but translating it into the form of "you know how I thought it couldn't possibly be done in less than twice the time you wanted? Well now it looks like it'll only take 50% more time...."
  
• Find another "want" and use it to expand the time. Sometimes its easier to do two things in twice the time than you could do one in the original time span. Instead of just reading the eartag barcode when you count the cattle, add a feature to the gizmo that records the hide color of the cattle (something you found out over beers at the Honky Tonk is something the Cattle guy always wanted).
  
• Find someone else to pay for it, or play your customers off against one another. "Well, I know its not in your budget, but if you let me make this one modification, then I can talk the sheep guy into paying half of it." If you swing this one right, you can get them both to pay full price and give you additional time... :cup:
  
• Play the FUD card: "You know I've heard that the evil cattle guy down the road is planning on *weighing* the cattle too....but, I know you can't afford that so I left it off my bid. You'll probably be *just fine* without that...."
  

Is it manipulation? I guess so. But the point is that they'll never understand why you need more time or money. The best you can do is to buy it from them with a combination of making it (at least look like it) is a huge consession on your part, that you're going out of your way to understand the problem and as a result coming up with something that's better for *them*, probably mostly at *your* expense.

 

I can de-parableize this if you'd like, but I really liked the cattle metaphor. All of the above is guaranteed tested on gullible IT customers though...

 

Give me ten years, and I'll have that brand on the gates of the greatest ranch in Texas. The big house will be down by the river, and the corrals and the barns behind it...Ten years and I'll have the Red River D on more cattle than you've looked at anywhere. I'll have that brand on enough beef to feed the whole country. Good beef for hungry people. Beef to make 'em strong, make 'em grow. But it takes work, and it takes sweat, and it takes time, lots of time. It takes years, :eek:

Buffy

[Symbology]

Buffy,

 

Thanks for the spectacular insights, and especially for staying in metaphor. It made it much easier to understand and follow. And thanks for the pointer to Red River - long before my time but educational to research. (I'm sure the trivia will come in handy later :naughty: )

 

It seems like you followed my intention, but just to be clear: There would be meta data fed to the system that told it whether it would be counting cows, sheep, or goats, and would reconfigure accordingly. But I follow and completely agree with how doing so tends to confuse the hell out of the cattle owners. And I also agree that it can take alot of convincing that this new fangled gate is robust enough to hold up vs good ol solid iron gates.

 

It reminds me of the time I flew from Monterey to San Fransisco beside a broad-shouldered, white-bearded Lockheed Martin engineer working on the YF-22 (back when it was YF). He was complaining about having two new engineers fresh out of college that only had 2 dimensional steel construction calculations under their belt and were using those to build 3 dimensional carbon composites. Their results were much too heavy, so he had to teach them the paradigm shift of utilizing the third dimension in the composite construction process to reduce the weight and structure and still meet the requirements.

 

If the customers don't understand what's different about that "strange looking black plastic stuff" vs the steel that they are used to... it can be a long edumacation process to get them to understand your new design.

 

Of course part of what impressed me at the time (I was about 25) was that the engineer I was talking to was probably the age of his two new engineers combined - yet was leading the way with the latest technology. I have always hoped to end up like him - still shredding the technology waves.

[Buffy]

And thanks for the pointer to Red River - long before my time but educational to research. (I'm sure the trivia will come in handy later ;) )

You're welcome! Howard Hawks is a *great* resource! :)

... but just to be clear: There would be meta data fed to the system that told it whether it would be counting cows, sheep, or goats, and would reconfigure accordingly.

Of course! You know that. I know that. But it scares the cow patties out of the customers, so *don't tell 'em*!

 

Think of it like being a magician. What magician do you know that tells you how they do their tricks (well, other than Penn & Teller, but if you know what they're doing, you can see the next level of complexity in customer obfuscation: but they're professionals: "give us a break, don't try what you're about to see at home.")?

...And I also agree that it can take alot of convincing that this new fangled gate is robust enough to hold up vs good ol solid iron gates. .... If the customers don't understand what's different about that "strange looking black plastic stuff" vs the steel that they are used to... it can be a long edumacation process to get them to understand your new design.

Hint: paint the black stuff silver...and that's really no joke! :evil:

Of course part of what impressed me at the time (I was about 25) was that the engineer I was talking to was probably the age of his two new engineers combined - yet was leading the way with the latest technology. I have always hoped to end up like him - still shredding the technology waves.

Then there's hope for you yet! Keep at it! :cheer:

 

For an individual to create a life, even a half-way decent one, he's gotta go beyond what he knows. .... Stick with what you think, and that's what you're gonna be stuck with. You may as well get out. Now! All of you... Miss Barrett's class dismissed. All of you dismissed for the rest of your crummy lives, :shrug:

Buffy

[Pyrotex]

...Is it manipulation? I guess so. But the point is that they'll never understand why you need more time or money....I can de-parableize this if you'd like, but I really liked the cattle metaphor. All of the above is guaranteed tested on gullible IT customers though...

Excellent paradigm and well-said. Huzzah!

Although I generally favor telling the truth, and providing what the customer needs, and "negotiating" with them in good faith and all that BS, the facts of the matter are:

 

1. There is NO WAY the customer will ever understand fully what you are doing for him.

 

2. There is NO WAY the customer will ever appreciate how clever and intelligent and wizardly and insightful you are in their behalf.

 

3. The customer WILL ALWAYS be your worst enemy, despite all of their intentions and promises to the contrary.

 

Therefore, as in The Buffster's paradigm, it is a mistake to tell the customer too much (especially, too much detail), it is a mistake to try to impress the customer with how much YOU know, and it is a mistake to trust that the customer will always work for their own highest good.

 

This is not to say that you should practice deception or manipulation. Oh, no, no, no!

 

You should practice compassionate deception and benevolent manipulation. :shrug: :cheer: :evil:

[DougF]

Buffy

Of course! You know that. I know that. But it scares the cow patties out of the customers' date=' so *don't tell 'em*! [/quote']

 

 

Pyrotex

You should practice compassionate deception and benevolent manipulation.

 

Very true words.

[Symbology]

Then there's hope for you yet!

Ouch

[Symbology]

Paraphrasing an earlier point made by Pyro: The difference between a genius and a wizard is that once a genius explains what he did, everyone goes "oohhh, I get it!" After a Wizard explains what he did, everyone is still left in amazement.

 

I just found an example in Edsger Dijkstra's eulogy from some years back. In it his friend said:

"How do you explain what it was like to take a course on mathematical methodology from Edsger, watching him demonstrate day after day his remarkable ability to solve problems that we can't solve ourselves, even after he elucidates the principles and techniques involved?"

[Symbology]

Pyrotex

You should practice compassionate deception and benevolent manipulation.

 

Speaking of which my girlfriend came across a spectacular book called Nasty People: How to Stop Being Hurt by Them Without Becoming One of Them http://www.amazon.com/Nasty-People-Without-Becoming-Bestselling/dp/0809244063 by Dr. Jay Carter.

[Note: for some reason the URL is doubling even though my post only has it once]

 

It does an excellent job of outlining the process by which an innocent person evolves into a nasty person under the oppression of another nasty person. It also does a good job of explaining how to quit exhibiting those traits if we see some of them within ourselves, as well.

 

As a test, I find that Anakin Skywalkers story maps to his process very well.

[Symbology]

I was given some additional insight today trying to untangle a data entity relationship diagram(ERD) at my new work. All the lines were in a big knotted mass, and I began to spread them out much like I have a mass of tangled computer cables.

 

My goal was to reduce the number of lines that crossed over. Something I discovered on an ERD at least is that if the lines are crossed it means that the object probably belongs between two other items, and is instead currently outside of those two items. Once I move it between the two items then the lines extend cleanly out in each direction. Much like unwinding a twisted cable.

 

And the data lesson learned there is that the said table itself identifies a series of paired relationships, more than just relying on the other tables. IE it may have hidden higher importance.

 

I'm not sure what the deeper lesson is there yet. But I'm sure it's coming.

 

Sorry to have been absent for so long but I've been traveling quite a bit. Now that things are settling down I may have more time to come visit.

[Overdog]

...And the data lesson learned there is that the said table itself identifies a series of paired relationships, more than just relying on the other tables. IE it may have hidden higher importance.

 

I happen to be a DBA, so I think I can confirm your suspicion that the table definitely and absolutely has hidden higher importance.

 

If you are seriously curious as to exactly how important, you could just delete it, and you will find out..:)

 

I wouldn't recommend it though...:rolleyes:

[Pyrotex]

I was given some additional insight today...I'm not sure what the deeper lesson is there yet. But I'm sure it's coming....

 

Yes, little symbolhopper,

the deeper lesson is this:

learn to control the inputs,

and you become master of the outputs.

 

Pyro

[Overdog]

And the data lesson learned there is that the said table itself identifies a series of paired relationships, more than just relying on the other tables. IE it may have hidden higher importance.

 

I'm not sure what the deeper lesson is there yet. But I'm sure it's coming.

 

It sounds like you are describing an "Intersection" or "Union" table.

 

Those relationship lines you were moving around define a 1 to many relationship between two tables. Child table has a foriegn key column which contains the value of a unique row in the Parent table (usually the "Primary Key").

 

But suppose you have two tables that have a Many to Many relationship. How would you set that up?

 

You create a Union table that goes between the two Parent tables.

 

For example, say you have Companies and People tables. Now say you have an Employee table. An employee is a Person, right? So their data goes in the People table. "Employee" is not an entity in and of itself as one might think, but is actually a relationship between People and Companies. So you set up the relationships 1 to many from People to Employee, and 1 to many from Companies to Employee.

 

Now you have a Many - Many relationship between Companies and People. A single person can be mapped to more than one company by adding multiple rows in the Employee table, and a Company can be mapped to more than one Person in the same way.

 

Other data that might be hidden in the Employee table would be something like "Hire Date" for example. Data relevant only to the relationship....

[Symbology]

Yes, little symbolhopper,

the deeper lesson is this:

learn to control the inputs,

and you become master of the outputs.

 

Pyro

 

Ah! :steering: The Corollary to

Who controls the past, controls the future

Who controls the present, controls the past.

-1984

 

And that also ties in with my martial arts study of the word "Before". :phones: As in move before their fist gets there. :confused:

 

Thanx Pyro!

[Symbology]

It sounds like you are describing an "Intersection" or "Union" table.

 

Those relationship lines you were moving around define a 1 to many relationship between two tables. Child table has a foriegn key column which contains the value of a unique row in the Parent table (usually the "Primary Key").

 

But suppose you have two tables that have a Many to Many relationship. How would you set that up?

 

You create a Union table that goes between the two Parent tables.

 

For example, say you have Companies and People tables. Now say you have an Employee table. An employee is a Person, right? So their data goes in the People table. "Employee" is not an entity in and of itself as one might think, but is actually a relationship between People and Companies. So you set up the relationships 1 to many from People to Employee, and 1 to many from Companies to Employee.

 

Now you have a Many - Many relationship between Companies and People. A single person can be mapped to more than one company by adding multiple rows in the Employee table, and a Company can be mapped to more than one Person in the same way.

 

Other data that might be hidden in the Employee table would be something like "Hire Date" for example. Data relevant only to the relationship....

 

Yes - Thanks Overdog. Would you agree that such things tend to be "meta data" - data about the data. And that it acts metaphorically like scaffolding to hold the once tangled lines apart so that things can move in and out of them?