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