Programmers with network engineering skills

Mon Mar 5 20:29:36 UTC 2012

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