[150817] in North American Network Operators' Group
Re: Programmers with network engineering skills
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Mar 5 18:47:30 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4F552755.2050102@ispalliance.net>
Date: Mon, 5 Mar 2012 15:46:11 -0800
To: Scott Helms <khelms@ispalliance.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 5, 2012, at 12:51 PM, Scott Helms wrote:
> Owen,
>=20
> I'd say that everyone's PoV on this is going to be experience =
driven. I've seen both approaches work (and both fail) and IMO the =
determining factor was matching the "right" approach with the project. =
I don't believe that you can develop a large scale project (large scale =
being a team of 12 or more full time developers working for more than a =
year on the same project) with people who primarily want to be network =
engineers. Its not a matter of skill set so much as it as what =
interests each group and they are very different.
>=20
I completely agree. In fact, such an effort is likely to fail in a =
rather spectacular and obvious manner if anyone were even to attempt it. =
I think everyone pretty much realizes the truth of this statement =
intuitively.
However, the bigger problem (from my experience-driven POV) is that it =
is not so intuitively obvious that developing a network-based product =
using a team consisting entirely of developers who view the network as =
an unnecessarily complicated serial port (which, really is about the =
approach most developers seem to take to networking) is also doomed to a =
certain amount of failure.
Usually that comes in the form of products that make invalid =
assumptions/assertions about the environment(s) in which they will =
operate.
For example, most apps designed to work with consumer electronics make =
the assumption that everything in a given household will be within the =
same broadcast domain as the device on which the app is running. =
However, in my household, the wireless network and the wired network are =
in separate broadcast domains. The consumer electronics are by and large =
on the wired network. The iPad, iPhone, and other portable =
network-capable electronics are not.
Faced with a support request regarding this problem, the universal =
answer has been to insist that this assumption is correct and that I =
should work with my router vendor to correct the problems in my network.
> Today I manage network engineers, Unix/Linux System Administrators, =
and Java (and Flex) developers and while there are tasks I can move from =
one group to another there is usually a best home for a specific =
project. Where I usually run into trouble is when I put a project into =
a non-optimal group usually because of deadlines.
>=20
Of course. But when the task crosses the skill-sets of the different =
groups, it's not always obvious which group is optimal or how to go =
about merging the correct blend of talents from each.
Owen
>=20
> On 3/5/2012 3:29 PM, Owen DeLong wrote:
>> Given my experience to date with the assumptions made by programers =
about networking in the following:
>>=20
>> Apps (iOS apps, Droid apps, etc.)
>> Consumer Electronics
>> Microcontrollers
>> Home Routers
>>=20
>> I have to say that the strategy being used to date, whichever one it =
is, is not working. I will also note that the erroneous assumptions, =
incorrect behaviors, and other problems I have encountered with these =
items are indicative of coders that almost learned networking more than =
of networkers that almost learned software development.
>>=20
>> Owen
>>=20
>> On Mar 5, 2012, at 9:53 AM, Scott Helms wrote:
>>=20
>>> I've played on both sides of the fence of this one, but I think the =
key piece is that you have to get enough software engineering for your =
tool to fit the life cycle it needs to follow and enough domain specific =
knowledge to for the tool to do what it exists to do. If you lack =
*either* of those you're going to suffer either through a tool that =
doesn't do what its supposed to or a tool that does everything it should =
right *now* but can't be efficiently expanded when the project scope =
suddenly expands. The real challenge is understanding what the scope of =
your project is and what it will likely be in ~4 years. If its not =
going to change much then the need for professional software engineering =
methodologies& practices is much lower than if you're going to have to =
add new features each quarter. Your target audience also has a big =
impact on what you need to do. Most internal projects have little need =
for a professional UI designer, but if you have a project that's going =
to touch thousands of people using a range of PC's and other devices you =
had better spend a lot of time on UI.
>>>=20
>>> tl;dr I don't think there is a *right* answer to be found because it =
depends on the project.
>>>=20
>>>=20
>>> BTW, just replying to Carlos in general not in specific.
>>>=20
>>> On 3/5/2012 11:08 AM, Carlos Martinez-Cagnazzo wrote:
>>>> Never said it was *perfect*. But you probably haven't a good (in CV
>>>> terms at least) prorgrammer assigned to you but didn't know the
>>>> difference between a TCP port and an IP protocol number. Or the
>>>> difference between an Ethernet and an IP address.
>>>>=20
>>>> For me at least (and I grant you that everyone's mileage may vary), =
it
>>>> has been a lot easier to teach networkers to program than the other =
way
>>>> around.
>>>>=20
>>>> I remember (not very fondly) the time when I was assigned to the =
team
>>>> which was going to write a DNS provisioning system, which was going =
to
>>>> be used by clients to get x.tld domains, and which had to =
periodically
>>>> generate the zone.
>>>>=20
>>>> A team of programmers, fully into the maintainability, lifecycle,
>>>> corporate IT thing was created. They didn't know what a DNS zone =
was, or
>>>> a SOA record, or a CNAME record for that matter. The project failed
>>>> before I could bring the matter of AAAA records up. Several tens of
>>>> thousands of dollars were spent on a failed project that could have =
been
>>>> saved by a different choice of programmers.
>>>>=20
>>>> The same problem was solved some two years later by a team composed
>>>> mainly of network engineers with one or two corporate IT =
programmers who
>>>> were in charge of ensuring lifecycle and integration with business =
systems.
>>>>=20
>>>> And a programming engineer (even if he/she is by default an
>>>> electrical/network engineer) is a far cry from a script kiddie. =
Sorry to
>>>> differ on that.
>>>>=20
>>>> cheers!
>>>>=20
>>>> Carlos
>>>>=20
>>>> On 3/2/12 8:35 PM, Randy Bush wrote:
>>>>>> In my experience the path of least resistance is to get a junior
>>>>>> network engineer and mentor he/she into improving his/hers =
programming
>>>>>> skills than go the other way around.
>>>>> and then the organization pays forever to maintain the crap code =
while
>>>>> the kiddie learned to program. right. brilliant.
>>>>>=20
>>>>> Always code as if the guy who ends up maintaining your code will =
be a
>>>>> violent psychopath who knows where you live. -- Martin Golding
>>>>>=20
>>>>> randy
>>>=20
>>> --=20
>>> Scott Helms
>>> Vice President of Technology
>>> ISP Alliance, Inc. DBA ZCorum
>>> (678) 507-5000
>>> --------------------------------
>>> http://twitter.com/kscotthelms
>>> --------------------------------
>>>=20
>>=20
>=20
>=20
> --=20
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
>=20
