Re: Programmers with network engineering skills

[Owen DeLong <owen () delong com>]

On Mar 5, 2012, at 12:51 PM, Scott Helms wrote:

> Owen,
>
>    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.
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.

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

> 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:
> >
> >      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, 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.
> >
> > 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 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.
> > >
> > > tl;dr I don't think there is a *right* answer to be found because it depends 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), it
> > > > has been a lot easier to teach networkers to program than the other way
> > > > 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 to
> > > > be used by clients to get x.tld domains, and which had to periodically
> > > > 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 been
> > > > 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 systems.
> > > >
> > > > 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 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.
> > > > >
> > > > > 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
> > >
> > > -- 
> > > Scott Helms
> > > Vice President of Technology
> > > ISP Alliance, Inc. DBA ZCorum
> > > (678) 507-5000
> > > --------------------------------
> > > http://twitter.com/kscotthelms
> > > --------------------------------
>
>
> -- 
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------