200 OK FAIL: Isolated Development Engineers


I work with numerous telecommunications equipment providers who
isolate their Development Engineers from customers -- and sometimes
even from their internal staff. The Wall of Isolation becomes evident
when you need to really understand how something works precisely.

All I want is to talk to somebody who can read the source code and
tell me what it's intended to do:

A major VoIP software developer with engineers in Montreal seems to
have a barrier between the US-based support staff and the Canadian
developers. Their professional services folks are pretty smart, but it
can be really quite difficult to get somebody to tell you how the
system is *supposed* to work in certain circumstances. And it's nearly
impossible to talk to somebody who can even view the source code. FAIL.

A VoIP software/equipment company based in Boston has a similar
problem; when trying to track down specific functionality, we've been
told by an employee that they dare not bother the Engineering people
who really understand it all. FAIL.

Another VoIP equipment company, based in Texas has a similar problem.
We've gotten the impression that the people who know the details are
really just too busy to describe precisely how it works. FAIL.

But it doesn't have to be this way:

A significant VoIP equipment company with offices in the Alameda seems
to have a different approach. It *is* possible, at times, to get help
from the developers. And there's an appreciation -- even at "lower
levels" of support -- for understanding *precisely* how the system
works. The support managers at this company are Software or Computer
Engineers, for the most part.

A major networking equipment company based in California sometimes
doesn't fail: their support engineers have access to the source code,
and occasionally they can really tell you precisely how it's supposed
to work.