6 ms·

Beware techies talking gobbledegook

27 points by foreigner 13y ago

khrist 13y ago
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 13y ago
  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 13y ago
    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.
- sergiosgc 13y ago
  The comparison with doctors is apt. Most of the time, I don't know enough about what my doctor is talking about to require more than generic explanation. If it is a simple problem, fine by me and I'm basically delegating my health into his competence. However, critically, if it is anything serious, I go and study it, enough to at least be able to talk about the subject. When I had lasik done, I knew as much domain specific jargon as my surgeon. The same applies to IT and company boards. For daily operations, hire a good IT exec and let him work. If, however, you are treating an exception, go learn enough IT to talk to the "doctors". Or get an IT guy on the board...
billyjobob 13y ago
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 13y ago
  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 13y ago
    "I am trying to find ways to improve the translation from a language people like to a language computers like."
    - RyanZAG 13y ago
      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!
belluchan 13y ago
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 13y ago
  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 13y ago
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.
zwischenzug 13y ago
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 13y ago
  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 13y ago
    We had to change the names of our API function calls when marketing updated our product name :(
    - Sandman 13y ago
      Which means you used a bad naming convention. I hope you updated them to something that is descriptive enough and yet won't need to be changed next time marketing decides to change the product name.
    - walid 13y ago
      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.
jliechti1 13y ago
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_why_questions/ http://lesswrong.com/lw/99c/transcript_richard_feynman_on_wh...
- StavrosK 13y ago
  Feynman was so good at explaining things. It always amazes me how he used very simple language, even when explaining things to university students.
- auvrw 13y ago
  as much as i admire the guy, i don't think a quote from a theoretical physicist is the most relevant to the article. consider this portion from the Perlis quote in intro to SICP: "Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands."
ChristianMarks 13y ago
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.
rjknight 13y ago
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_ 13y ago
  Can you predict all possible effects of someone smart joining the board? Better not stirring the pond!
  - walid 13y ago
    LMAO!
incision 13y ago
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 13y ago
  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?
ENGNR 13y ago
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.
_random_ 13y ago
Clearly the board has to be fired for not keeping up to date with modern knowledge.
einhverfr 13y ago
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 13y ago
  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 13y ago
    > 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.
deleted 13y ago
[deleted]
alextingle 13y ago
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".
deleted 13y ago
[deleted]
Zenst 13y ago
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.

27 points by foreigner 13y ago

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 13y ago
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 13y ago
  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.
sergiosgc 13y ago
The comparison with doctors is apt. Most of the time, I don't know enough about what my doctor is talking about to require more than generic explanation. If it is a simple problem, fine by me and I'm basically delegating my health into his competence. However, critically, if it is anything serious, I go and study it, enough to at least be able to talk about the subject. When I had lasik done, I knew as much domain specific jargon as my surgeon. The same applies to IT and company boards. For daily operations, hire a good IT exec and let him work. If, however, you are treating an exception, go learn enough IT to talk to the "doctors". Or get an IT guy on the board...

billyjobob 13y ago

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 13y ago
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 13y ago
  "I am trying to find ways to improve the translation from a language people like to a language computers like."
  - RyanZAG 13y ago
    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!

belluchan 13y ago

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 13y ago
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 13y ago

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.

zwischenzug 13y ago

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 13y ago
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 13y ago
  We had to change the names of our API function calls when marketing updated our product name :(
  - Sandman 13y ago
    Which means you used a bad naming convention. I hope you updated them to something that is descriptive enough and yet won't need to be changed next time marketing decides to change the product name.
  - walid 13y ago
    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.

jliechti1 13y ago

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_why_questions/ http://lesswrong.com/lw/99c/transcript_richard_feynman_on_wh...

StavrosK 13y ago
Feynman was so good at explaining things. It always amazes me how he used very simple language, even when explaining things to university students.
auvrw 13y ago
as much as i admire the guy, i don't think a quote from a theoretical physicist is the most relevant to the article. consider this portion from the Perlis quote in intro to SICP: "Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands."

ChristianMarks 13y ago

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.

rjknight 13y ago

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_ 13y ago
Can you predict all possible effects of someone smart joining the board? Better not stirring the pond!
- walid 13y ago
  LMAO!

incision 13y ago

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 13y ago
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?

ENGNR 13y ago

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.

_random_ 13y ago

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

einhverfr 13y ago

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 13y ago
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 13y ago
  > 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.

deleted 13y ago

[deleted]

alextingle 13y ago

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".

deleted 13y ago

[deleted]

Zenst 13y ago

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.