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


Reply via email to