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