Re: Programmers with network engineering skills

[Owen DeLong <owen () delong com>]

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