If someone is interning at a company that does not follow best practices or any of the software methodologies that people who seem to know what they are talking about tend to advocate, should they leave?
Can an internship actually be harmful to a young developer if it isn't a good environment?
Would they be better off using the time for independent study?
I'd have to say "No!".
In an interview situation, I can't imagine thinking, "Well, he's never worked professionally, but look at all the books he's read!" vs. "Ok, so he hasn't used SCRUM, but at least he's delivered product on-time in the past".
Some experience, no matter how bad a situation, is better than none, just about always.
Besides, who's to say you can't find time to read those books anyway? In an interview, if you told me about your situation, I'd probably ask, "Ok, so what did you do to make it better?"
Honestly, you will probably not learn anything technically, but it will give you excellent exposure to the standard organization. There are very few organizations that follow good programming techniques, but the key to this is to learn how to survive in these companies. Because if you are a good developer in these companies you or any company you will move up faster than the bad developers.
My first real job was with an organization like you describe, and I was able to move up from jr. dev to sr. dev in the organization in under a year because I demonstrated good development practices through my code and subtly forced everybody else to follow my model. It has been all up hill since then, so working in a bad environment is good, if you are confident that you can learn good coding from independent study.
So do both.
No. You don't always get to work in the ideal shop.
Internships allow you to see both the good and the bad of what software development is. Try to leave your mark on them. Work with them, and do things right as long as it doesn't cause conflict.
Even if the company doesn't follow best practices there is still a lot to be learned that self study will never accomplish.
For one thing, it is a major learning experience to see a large software project fail due to small failures along the way. Anyone, intern or not, should learn from these mistakes. It is one thing to know that you should not do XYZ, and if life were perfect it would be ideal never to see the outcome of doing said action. But since life is not perfect and we all make mistakes seeing the outcome of what you have always been told was a "bad thing" can in fact be quit the eye opening experience. It would be at preciously that moment that you realize EXACTLY why XYZ was a "bad thing".
So to make the long answer short, unless the company is harmful (as in hostile work environment harmful) then there are valuable lessons to be learned.
Although you may not find yourself picking up a lot of new technological skills -- certainly not ones that you're going want to re-use -- don't underestimate the utility of learning how to avoid the traps of bad development patterns. Anti-patterns are a major area of study in software engineering, so instead of simply raising your nose at the bad things you see, document them. Not for nefarious purposes, but in order to understand why they're bad. You will either learn more practices to avoid, or you'll learn that they have good reasons for what they're doing, which might just be the case.
No, experience trumps almost everything else, even if that experience isn't ideal (because, you know, no matter where you work, it won't be ideal).
Just by working with other people, on a project that's "real", you're going to learn some very useful skills. They may not be the skills you initially wanted to learn -- you may not learn the perfect implementation of the gleaming best practices or design patters you wanted to -- but you'll learn how software is actually made, most of the time. Most places aren't doing the best things even some of the time.
Try to approach your time as an intern as a way to soak up whatever knowledge you possibly can. Just by virtue of doing something for 40 hours a week, you'll gain a qualitatively different set of skills than you could otherwise. I'd be willing to bet you will learn some good technical skills -- maybe it's some debugging tricks, or code-browsing tricks, or what-have you, that your co-workers have evolved to compensate for their less-than ideal practices. Almost undoubtedly some neat implementations that you wouldn't see otherwise. Definitely some great stories, one way or another. You might even find a mentor.
The thing is: computers can only teach you so much. The internet can only teach you so much. Stack Overflow can only teach you so much. You will learn a vastly different set of things -- many of them way more valuable -- by interacting with real people, no matter how deficient their processes may seem, than you would in an independent project.
Welcome to the sausage factory, and have fun :)
Any experience can be a helpful experience.
The determining factor is what you do with the experience. If you can recognize a bad environment, you can learn a great deal about what not to do.
A good experience speaks for its self.
Don't underestimate what a great learning experience it can be to learn how not to do things.
There are a large set of decisions that have to be made in an organization. Many of them are in the set of "best practices" you already know about. Even if an organization doesn't follow all of that set that you happen to know, it's likely that they're doing other things right. You can learn from their anti-patterns as Jason suggested; you can also try to learn what things they're actually doing well.
As an example, in one internship I did years ago, I was in a hard-working group, but they were doing some things inefficiently and with less quality than they wanted. Coming in as an outsider, I was able to see the need for some small but critical core pieces of technology. I built them and it make a big difference. When looking for jobs later, I have been able to point to that experience as an example of initiative and learning. That's the anti-pattern / make it better part. While watching how they worked, I also learned that response time was critically important to their customers, and sometimes it's more valuable to get something rough out to people and then refine it with them than to spend years polishing it first.
Internships are mostly for gathering work experience and recommendations so you can get your first "real" job.
It's a huge plus if you love the internship and learn a lot. But, the real point is just showing up on time, working hard, finishing your tasks on deadline, showing you can work well in a team, and getting the recs/references to show it. It's almost better if your internship isn't perfect, because you can show you can focus on finishing projects and the company's goals even when they don't totally float your boat.
Leaving a job after just a few months isn't necessarily the worst black mark on your resume (sometimes things just don't fit), but leaving an internship early would be a pretty big red flag if I were the hiring manager. To me, that suggests you can't handle adversity or work with others, or hold some ubernerdy principle (they say they're doing AOP but they aren't really doing AOP!) above actual business goals like shipping product. Honestly, only something totally out of bounds really explains leaving a <6-month internship early, like a personal/family emergency or your boss sexually harassing you. Chances are that every place you work will do zillions of things wrong (even places like Google aren't all they're cracked up to be), it's important to think positive and focus on achieving goals.
The great thing about an internship is it does end after a few months, even if the experience totally sucks, you can make the most of it and know you'll be outta there soon enough and part on good terms. And I wouldn't worry about having your neural pathways somehow tainted by bad methodologies, if you've got a critical mind you'll recognize things like that and move on. There's always something to learn, even if it's just a bunch of counter-examples of bad practice you can use in your next job to argue your way out of doing something stupid again.
Get the best internship your qualifications/connections can get you and move up from there.
No, there are many different methodologies out there with varying degrees of success I think. If you want the company you work for to use a particular methodology then you may have to make a case for why they should switch to that as you may have an old company that uses Waterfall quite successfully and trying to put in Agile may be like putting the square peg in the round hole.
The internship can be harmful if a young developer believes that once you learn something that is the only way to do it and there can never be any re-learning of skills. Alternatively, if the environment is so bad that it makes regular appearances on WTF then perhaps it may be harmful.
Independent study may be more harmful as there isn't necessarily the same supervisory overhead. After the internship, your next employer could ask for a reference from your previous supervisor, while if you do independent study, who is keeping an eye on you in that case?
If you are taught bad practices without knowing, then maybe it would be "harmful to a young developer", but easily corrected. However, you claim you already know the practices are bad. You now have an opportunity to watch first hand and learn why they are bad. If you are correct, and are able to log examples of error and waste that would have been avoided by good practices, you might even consider presenting your findings to the right manager at the right time. Whether you are rewarded or punished depends on many factors, but it sounds like a great learning opportunity.
I am 10 months into a 12 month internship and boy what I can say is this. I won't trade this experience for anything else. I used to side code for years and thought I was good because I could write a desktop inventory management system using c++builder. Where do i start on how wrong I was coming and working with the true experts, it has totally transformed my understanding of software development and has put me on track to my goal of Developer/Architect.
Leave and study? Bah, no, your goal should be to write as much code for them as possible, at the highest standard you can manage. If you're interested in software process (which it sounds like you are), look hard at what's going on and compare what the experts 'know' is the right way to do things to what the company is doing, and see if you can find advantages in their way of working.
If nothing else, writing code without worrying about long-term maintainability is extremely fun!