
Beware techies talking gobbledegook - foreigner
http://www.ft.com/cms/s/2/8f108044-6c31-11e3-a216-00144feabdc0.html?ftcamp=published_links%2Frss%2Fcomment%2Ffeed%2F%2Fproduct#axzz2pPokNbsA
======
jliechti1
Sometimes it's not always possible to explain something in sufficient detail
to someone who has no concept of what you are trying to explain.

Feynman explains this really well when trying to answer a question about
magnets:

 _" Of course, it's an excellent question. But the problem, you see, when you
ask why something happens, how does a person answer why something happens? For
example, Aunt Minnie is in the hospital. Why? Because she went out, slipped on
the ice, and broke her hip. That satisfies people. It satisfies, but it
wouldn't satisfy someone who came from another planet and who knew nothing
about why when you break your hip do you go to the hospital... when you
explain a why, you have to be in some framework that you allow something to be
true. Otherwise, you're perpetually asking why."_

 _" I can't explain that attraction in terms of anything else that's familiar
to you. For example, if we said the magnets attract like if rubber bands, I
would be cheating you. Because they're not connected by rubber bands. I'd soon
be in trouble. And secondly, if you were curious enough, you'd ask me why
rubber bands tend to pull back together again, and I would end up explaining
that in terms of electrical forces, which are the very things that I'm trying
to use the rubber bands to explain. So I have cheated very badly, you see."_

The key quote being:

 _" I really can't do a good job, any job, of explaining magnetic force in
terms of something else you're more familiar with, because I don't understand
it in terms of anything else you're more familiar with."_

Video: [http://www.youtube.com/watch?v=wMFPe-
DwULM](http://www.youtube.com/watch?v=wMFPe-DwULM)

Transcript:
[http://lesswrong.com/lw/99c/transcript_richard_feynman_on_wh...](http://lesswrong.com/lw/99c/transcript_richard_feynman_on_why_questions/)

~~~
spion
I feel that here Feynman is reluctant to admit that the answer is - we don't
know. While we know a lot of the properties of magnetic fields and how they're
amplified in magnets, afaik we have no idea what they're "made of" yet (if
they're made of anything at all) or by what means they exert force at a
distance.

The fields are presently among of our base concepts. Like the atom was, until
the discovery of the electron and nucleus around ~1900.

What he does capture well is that you always have some kind of a base which
you accept.

~~~
DennisP
Well we might not know what electrostatic attraction is, but google "magnetism
relativity" and you'll find that magnetism comes from relativistic effects of
the motion of electrons. It's really nifty, and simple to understand if
relativity is already a concept you're familiar with.

(That might be what you meant, but learning this a couple years ago blew my
mind so I had to share.)

~~~
spion
Yes, thats it! It turns out we (humanity) did know more, its just that I did
not :) Thanks.

------
incision
The author is conflating an awful lot of things which are not necessarily
similar or even necessarily technical challenges to draw a deflecting
conclusion about "gobbledegok".

It's a warning / apology for the logical, competent, altruistic and forthright
executives of the world not to be further misled by the self-serving, evasive,
babbling "geeks".

Something like a condensed _Make Mine Freedom_ [0] for the "dangers" of
technology.

 _> "But the first step is the simplest and the most important: like Dennis,
we need to ask challenging questions, admit that we do not understand
“gobbledegook” and demand answers."_

What a concept.

Just _demand_ answers to something so far beyond your current comprehension as
to be nonsensical.

What's in the best interest of the company / country here?

Is it really attempting to synthesize three decades, a handful of degrees and
years of domain-specific knowledge into a 5-minute PowerPoint deck? Or might
we all be better served by replacing complacent, technically illiterate board-
sitters with people who care enough to come prepared and stay current?

0:
[http://www.youtube.com/watch?v=mVh75ylAUXY](http://www.youtube.com/watch?v=mVh75ylAUXY)

~~~
rjknight
You think Steve Jobs (insert other tech CEO if you prefer) wouldn't demand
answers from finance specialists or lawyers, and wouldn't be equally
dismissive of them if they replied with obfuscatory jargon?

------
zwischenzug
In my experience, it's not techies that talk gobbledegook, it's that those
signing off IT work don't want to hear about problems ("this will take years
to implement"), so it's those who pull the wool over their eyes that get to
talk to them.

I've seen a FTSE-100 company destroyed because of adherence to buzzwords and
industry standards (nothing inherently wrong with that) without - crucially -
any attention to the details of applications to their business. Which is what
this Dennis did.

~~~
sebcat
I've seen entire codebases riddled with method names that could've been taken
straight from the latest sales pitch made up by Marketing. I think it depends
on what kinda company you are. The more "sales-driven" (for lack of a better
wording) your company is, the more likely you are to end up with words like
"human assisted training" to describe a non-AI related configuration process.

I would say techies also get caught up in this behavior sometimes.

~~~
hkmurakami
We had to change the names of our API function calls when marketing updated
our product name :(

~~~
walid
Well I have to say that some command/API names on unixes for example are
horrible. What's up with killing processes. Can't we just say terminate. Since
software is mostly developed by a geeky bunch we sometimes forget that we are
actually making something to be presented in an appealing manner to a
buyer/licenser.

------
billyjobob
In academia I would often meet people who were unable to explain what they
working on in language I could understand, even though their PhDs were in the
same field as my own. Sometimes I would have to interrogate them for more than
ten minutes, like getting blood from a stone, before I got a clue what it was.
I think if you can't explain what are you doing in general terms in 30 seconds
to a layman you probably don't really understand what you are doing.

~~~
ahomescu1
Not every research topic can be explained to a layman in 30 seconds
(personally, I think it's cruel to expect that). Some research work only makes
sense within a certain context or background, and it can sometimes take a lot
more than 30 seconds to explain that context, or the background behind it. The
academic him/herself can understand the work very well, because he/she also
has a very good graps of the related concepts.

For a concrete example, I work on compiler research. To explain my work to a
layman, first I have to explain "compiler"; for that, I need to explain
"native code" and "programming language". That can take a lot more than 30
seconds.

~~~
StavrosK
"I am trying to find ways to improve the translation from a language people
like to a language computers like."

~~~
RyanZAG
Well done, you've said "compiler research". You've just spent 10 seconds
explaining 'what is mathematics' instead of what project he's actually working
on. Plus your explanation would leave someone with very little idea about
computers even more confused: is he going through some novel and translating
it into another language like french? You made him sound like a translator.

The CEO you've now explained what he does now has a good idea - translating
between human languages usually loses some of the intricacies of the statement
and makes it seem unnatural. It's better to just get someone to write directly
in french rather than translating it from english, right? So the CEO will fire
the compiler researcher and hire someone to code in ASM. Good job.

I'm being silly here, but the point still stands: explaining something complex
is fraught with dangers when there is no mutual understanding of the subject
matter. You might think you've explained something, and the listener might
thing he has understood, but in reality you have now simply created completely
invalid assumptions in a person's mind. The greatest example of this I've seen
is regarding quantum mechanics and observation collapsing the wave. There is a
whole quasi-spiritual movement that now believes that the world is shaped by
conscious observation - talk about missing the point!

~~~
StavrosK
Well, there's a minimal set of things you must mention to fully explain
something. The only way to explain his PhD fully would be to read his PhD
dissertation, as that's what the definition of a dissertation is.

Summarizing is about maximizing the amount of information conveyed per word.
Saying "you have failed to explain what he does in two sentences" is a bit
silly, since, if one could fully explain his PhD in two sentences, it wouldn't
be a PhD.

------
rjknight
If IT is this important then maybe it would be a good idea for the firms
affected to have people who understand it on the board, rather than relying on
Dennis.

~~~
_random_
Can you predict all possible effects of someone smart joining the board?
Better not stirring the pond!

~~~
walid
LMAO!

------
khrist
interesting article, when I visit doctor I have similar feelings, same thing
applies to law, finance and other specialized fields. But my energies permit
me know only so much. So its essential we watch out for jargon abuse. Most of
the times when someone is heavily using the technical bits, they are trying to
hide their incompetence. If a person knows about something well and is
explaining to a layman, they will do their best to explain it as plainly as
possible. Gobbledegook signifies something festering underneath

~~~
dataisfun
Not sure if the comparison with finance is apt. Financial sophistry layered
complexity on complexity without a robust understanding of principles (i.e.,
housing prices don't always go up, hiding debt and ownership in millions of
small pieces spread around will create a mess), whereas computing grows
intelligently (most of the time) from real world problems that need
addressing.

~~~
JanezStupar
Oh they understand principles pretty well (I get comission x% and I don't
fucking care about everything else). The layering of sophistry is there so
they can obfuscate them from you. They also use it for maintaining plausible
deniability.

------
alextingle
Board level decisions are not concerned with the details of project
implementation. Rather they concern risks, returns, costs and alternatives.

If some "techie" has presented a bag of buzzwords to the board, then someone
has failed to recruit a competent technical manager. Someone who's job is to
understand both the technical _and_ the strategic domains. Directors would be
best to spend their time recruiting, rather than learning Vim.

OTOH, sometimes the board fails to realise that they are actually running a
software company. For example, many directors still believe they are running a
"bank", when the vast proportion of their business is software development. In
such cases, complaints like this amount to little more than pining for the
"good old days".

------
belluchan
Learning to understand the technobabble is hard even for engineers who aren't
familiar with a system. If you're not an engineer the best you can do is hope
to understand the cliff notes. And understanding something about the software
isn't going to help much anyway. In the examples of failures the author lists,
the people who understood the system, the experts you'd turn to for
understanding, probably didn't expect the failures that came about. So if you
are learning to understand the system from them, how would you spot them? It
seems like a bad argument from start to finish. Hire someone you can trust
that is known to be competent, have them audit the software. Don't do it
yourself.

~~~
einhverfr
I am convinced at least some of it is there to confuse the engineers who would
try to understand the system.

For example, I tell people who want to learn networking "do NOT start with the
OSI model. Start by learning how TCP/IP actually works and how it was
designed. Then learn how and why the OSI model was designed." But a lot of
people insist on going the other way, I think _because_ it is more confusing
and obfuscates more than it clarifies.

------
gametheoretic
First we lived in a post-9/11 world, now we live in a post-2008 world. Insofar
as as the opening lines of articles are concerned.

------
ChristianMarks
Having to explain technical concepts to a self-styled hard-nosed character can
be extremely tiresome and bad for the cardiovascular system. The subject is
specialized and deep enough for the most supreme intellect.

------
ENGNR
You have to applaud anyone seeking to know more about technology. And the more
your customers know, the more likely they are to choose the optimal solution
(yours?) rather than some slick marketing pitch that will inevitably fail to
deliver the promises made.

Some people argue that you can't condense all of that knowledge into phrases
non-technical people can understand, that's rubbish. Consider what they
already know, then give an overview at that level with a list of benefits.
Wherever they inquire then just explain that part at the next level down.

------
einhverfr
One of the things I have often noted is how theories which don't match reality
very well often trump reality in terms of explanations. For example, TCP/IP is
a 4-layer network stack, while the OSI model is 7 layers. These models are
_fundamentally different_ and understanding the _differences_ is often key to
understanding design decisions for OSI protocols ported to TCP/IP (H.323 being
a good example).

But people talk as if TCP/IP follows the OSI model. It doesn't. Often
understanding that it doesn't and why it doesn't is a good first step to
understanding why it works the way it does. So that is top of my list.

THere are other issues. For example, when another techie is speaking
gobbldiegook, it is way too easy to project meaning onto what is said so that
misunderstandings develop. For example, I have written frameworks for building
object frameworks. These are not object factory factories (but rather services
to offer object frameworks, for example generalized service locator API's for
locating stored procedures, allowing a looser coupling than most people have).
However, when someone says "its an object factory factory" very often the
simplest response is "well, sort of, if you are the factory worker!"

~~~
walid
Don't be baffled. When was the last time you went to the movies to see the
ordinary life of that normal person called Tony Stark. Buzz is what we desire.
As for the TCP/IP and OSI differences, you are being slightly iffy. While they
are definitely designed differently, TCP/IP only coalesces OSI layers to make
programming simple for the task at hand.

~~~
einhverfr
> While they are definitely designed differently, TCP/IP only coalesces OSI
> layers to make programming simple for the task at hand.

But it _doesn 't_ except if you use the cliff notes version of the OSI model.
That's my point. Otherwise, H.323 would look like SIP, which it doesn't.
Protocols designed for an OSI model look _fundamentally_ different than
protocols designed for a TCP/IP model.

Let's look at H.323 since that is the example I am using. The protocol is a
beast to work with over TCP/IP because it was not designed for that. It was
instead designed for a unified OSI network where virtual circuits could be
requested to handle voice and video information. Those don't exist in TCP/IP
which has _no_ concept of a virtual circuit and so over TCP/IP, you use a new
TCP connection everywhere you'd use a virtual circuit because that is the
closest equivalent. It isn't really an equivalent however which makes the
protocol very, very difficult to deal with in terms of firewalls, etc. Compare
with SIP which just passes everything across a single TCP connection hitting a
well known port.

The difference here is that the basic assumptions of what the network _can do_
are different. TCP/IP assumes at its basis that you have a simple, dumb packet
switched network that really isn't capable of doing anything else. OSI assumes
you have an intelligent network capable of routing packet-switched and
circuit-switched information together. They are _totally different design
criteria_ and _at best you can say TCP /IP is a very narrow subset of what OSI
is designed to do._

What this means, effectively, is that you either have to strip down the OSI
network in theory to match TCP/IP (which is useless) or you end up with
something that doesn't really match. Either way there is no way of
understanding H.323 without understanding the OSI model to a level in which
the fundamental differences with TCP/IP matter and that requires knowing the
basics not only of packet-switched networks but also circuit-switched networks
too.

~~~
waps
How about we simply agree that OSI is a monstrous "designed by 99 committees"
theory and accept that it is not used in practice ? Actual networking stacks
do not follow it. Hell they don't even follow TCP/IP's layers, but at least
there they make an effort to make it look like they do (e.g. in networking
hardware, or for that matter the linux kernel, there is no actual "layer 3
routing" step that is distinct from the "layer 2 switching" step).

OSI is an ancient, dumb, wrong, 10000000000000 feet architect view of
networking. Do not learn anything about it, you'll do yourself a favor.
Ethernet is NOT OSI layer2, IP is NOT layer3, and especially do not think TCP
is OSI layer 4.

~~~
einhverfr
> _How about we simply agree that OSI is a monstrous "designed by 99
> committees" theory and accept that it is not used in practice ?_

Partly agreed. It's worth noting however that the PKI associated with SSL
(X.509) is an OSI thing and so understanding OSI concepts is still rather
important. This is also why X.509 certificates IMO feel a bit foreign in terms
of structure and they tie in closely to LDAP concepts (a stripped down version
of OSI X.500) rather than more internet-y directory concepts like DNS where
everything is a text string and human readable.

> _Hell they don 't even follow TCP/IP's layers, but at least there they make
> an effort to make it look like they do_

My point was that TCP/IP and OSI are just fundamentally different. They are
culturally different. They have different goals. You can understand TCP/IP
better on its own than through OSI. You can't understand OSI by using TCP/IP
as a sole reference.

> "OSI is an ancient, dumb, wrong, 10000000000000 feet architect view of
> networking."

I think it is more correct to understand OSI in context, namely that it was a
network model designed to support the OSI protocol stack. This stack was
intended to fully merge circuit and packet-switched networks (effectively
merging phone switches and the internet). This means you have, effectively, an
intelligent network with possibly intelligent terminals, which are capable of
doing both circuit- and packet-switched networking on top. OSI protocols
ported to TCP/IP like H.323 make perfect sense if you understand that they are
assuming they can open phone calls (but in the process of porting them to
TCP/IP, they have to use one TCP/IP connection for each phone circuit they
would otherwise open). This is furthermore why the network perimeter controls
designed for H.323 involve what amount to phone switchy things instead of
things like firewalls (and why a simple packet filter won't work).

In terms of the value of not learning it, I think the best approach honestly
is to learn TCP/IP without the OSI model first, and then learn the OSI model
and what the OSI stack was designed to do after. This gives you whole layers
of insight, not into TCP/IP but into OSI protocols ported to TCP/IP.

------
_random_
Clearly the board has to be fired for not keeping up to date with modern
knowledge.

------
Zenst
Techs don't talk gobbledegook, just that non tech's listern with the wrong
mindset. This is why we have managers, to act as translators - it is what they
do and are paid to do.

The day when an employment contracts is shorter than a CV is when techs do not
need to talk gobbledegook. A CV explains your liftime of skills and experience
and a employment contract explains how you are paid and what you do to gain
that pay. With that in mind, techs deem life too short to expand upon what
people do not understand. WIth that you always get the sturborn person who
wants to know details they need not know and with that we ask that person for
a charge code for our timesheet and play one problem of techs of against
another.

