[150812] in North American Network Operators' Group
Re: Programmers with network engineering skills
daemon@ATHENA.MIT.EDU (Scott Helms)
Mon Mar 5 15:52:33 2012
Date: Mon, 05 Mar 2012 15:51:33 -0500
From: Scott Helms <khelms@ispalliance.net>
To: Owen DeLong <owen@delong.com>
In-Reply-To: <36D900B5-A5C3-449D-B6E3-FD2FD4D495DE@delong.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Owen,
I'd say that everyone's PoV on this is going to be experience=20
driven. I've seen both approaches work (and both fail) and IMO the=20
determining factor was matching the "right" approach with the project. =20
I don't believe that you can develop a large scale project (large scale=20
being a team of 12 or more full time developers working for more than a=20
year on the same project) with people who primarily want to be network=20
engineers. Its not a matter of skill set so much as it as what=20
interests each group and they are very different.
Today I manage network engineers, Unix/Linux System Administrators, and=20
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. =20
Where I usually run into trouble is when I put a project into a=20
non-optimal group usually because of deadlines.
On 3/5/2012 3:29 PM, Owen DeLong wrote:
> Given my experience to date with the assumptions made by programers abo=
ut networking in the following:
>
> Apps (iOS apps, Droid apps, etc.)
> Consumer Electronics
> Microcontrollers
> Home Routers
>
> 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, incorr=
ect behaviors, and other problems I have encountered with these items are=
indicative of coders that almost learned networking more than of network=
ers that almost learned software development.
>
> Owen
>
> On Mar 5, 2012, at 9:53 AM, Scott Helms wrote:
>
>> I've played on both sides of the fence of this one, but I think the ke=
y 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 know=
ledge to for the tool to do what it exists to do. If you lack *either* o=
f 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 the=
n the need for professional software engineering methodologies& practice=
s is much lower than if you're going to have to add new features each qua=
rter. 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 usin=
g a range of PC's and other devices you had better spend a lot of time on=
UI.
>>
>> tl;dr I don't think there is a *right* answer to be found because it d=
epends on the project.
>>
>>
>> BTW, just replying to Carlos in general not in specific.
>>
>> 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.
>>>
>>> For me at least (and I grant you that everyone's mileage may vary), i=
t
>>> has been a lot easier to teach networkers to program than the other w=
ay
>>> around.
>>>
>>> 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 t=
o
>>> be used by clients to get x.tld domains, and which had to periodicall=
y
>>> generate the zone.
>>>
>>> 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 b=
een
>>> saved by a different choice of programmers.
>>>
>>> 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 sy=
stems.
>>>
>>> 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.
>>>
>>> cheers!
>>>
>>> Carlos
>>>
>>> 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 programm=
ing
>>>>> skills than go the other way around.
>>>> and then the organization pays forever to maintain the crap code whi=
le
>>>> the kiddie learned to program. right. brilliant.
>>>>
>>>> Always code as if the guy who ends up maintaining your code will be =
a
>>>> violent psychopath who knows where you live. -- Martin Golding
>>>>
>>>> randy
>>
>> --=20
>> Scott Helms
>> Vice President of Technology
>> ISP Alliance, Inc. DBA ZCorum
>> (678) 507-5000
>> --------------------------------
>> http://twitter.com/kscotthelms
>> --------------------------------
>>
>
--=20
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------
