Scott, I fully agree with you. In fact, I was just commenting on *my* experiences and never implied that they would / should apply the same for everyone.
cheers! Carlos On 3/5/12 3:53 PM, 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 >> > >