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