The unfortunate reality is that you will actually meet these situations in the real world. My memory of group projects in school (caveat: although I'm a software dev now, I have a degree in the humanities) more or less mirrors yours: most of the time, you got maybe one other person in the group who pulled their own weight and you basically had to resolve things between the two of you. That being said, here are the strategies that have worked for me in the past:
Assume you're going to do all the work
I realize that everybody's just learning the system, which in and of itself is going to ramp up the difficulty level right there, but chances are your professors aren't giving you something that's undoable. In fact. there's a solid chance that you just might be able to take on the whole thing yourself. So, delegate responsibility and all that but if guys aren't meeting deadlines, just fill in the work for them.
Don't think of this as doing someone else's work, think of this as taking advantage of the system. You want to be a great programmer? The difference between good programmers and bad ones is that good ones do a lot of it. Theory is nice and all, as is talking with other programmers, but at the end of the day the only way to really and truly learn about the process of programming is to just write a lot of code. On top of that, if you have a TA who will go in and critique the work beyond running a .exe to see if it works, that's, like, double the opportunity: if you write all the code, all the code review you get is stuff that applies to you.
Think in terms of Agile, or at least try to.
One of the tougher things about starting out is that you're only just aware of the concepts of coding (or maybe you're one of those guys who's been doing it since they were 5, who knows) is that you don't necessarily have experience with software development methods like Agile. You may want to look into how it's done (check out Scrum as well, which is kind of a submethod of Agile). Among other things, it tends to let you know early on who is going to help out and who is not.
A brief synopsis of some of the things that having an Agile-based mindset might lead you to do in a group like this:
- Conduct a "daily standup" between everyone where everyone talks about what they did in the last 24 hours and what they'll be doing in the next 24.
- Get together to break down your project into smaller sub-projects and finally "stories" that each might take only a couple to few hours to finish which you can then dole out to everyone.
- Go by a general philosophy that what you want to get off the ground first is something that meets the minimum requirements, and then, once you've fulfilled those, go back and add more features. Sometimes, yes, this does require you to go back and refactor some code you've already written, but a. this is what we do in the real world, and b. you'd be surprised at how often you don't have to do that.
- Have periodic get-togethers where everyone can present their work to everyone else. Code review isn't necessary at this point, although if people are game to do that, sure. What you're really after at these points, though, is actual working stuff that everyone can look at to see if/how the different parts work.
Consider some sort of version control.
Even if this just means opening up a Github account, this is a really good idea. For one thing, as before it allows you to see really, really quickly who the slackers in your group are (additionally I know that there's a paradigm in college that says you can get away with doing everything at the last minute - that doesn't really fly with software development and this is a good point for folks to figure that out). On the flip side, if someone gets into a car accident you aren't left trying to explain that to the professor on the day the assignment's due if they've been checking their work in.
Also, and perhaps most importantly in your situation, version control actually gives you a bit of extra freedom to try new things that may or may not work out. Let's say you've put together that WinForms app or whatever that accomplishes the absolute minimum that the prof is expecting out of the assignment, but you get extra credit if you can write it in WPF. With good source control you can check out the UI, make all kinds of sweeping changes to it as you refactor it, and if you get boxed into a corner and it's Sunday night and the project's due Monday morning, you can always back out of your changes and go back to that version you know will at least get you a B.
That applies to all your colleagues as well. If you get a stable build and then someone breaks it, the worst case scenario is that you can always rewind to the last stable build. I think that has happened to all of us in the real world.
I understand that your colleagues don't know how to use source control. The good news is, it doesn't take that long to learn. The hour you spend helping them will pay you back in spades (if nothing else, you can use the check-in data as evidence that folks didn't actually do any work).
Keep a dialogue with your professor and/or TA.
I know, nobody likes to be a snitch, and if your dev program is extra small, it might suck to have to work with people in the future whom you've kind of sandbagged on this project. The way to avoid this is not to go by the maxim that "snitches get stiches", it's to constantly be in a dialog with your prof whether people are pulling their weight or not.
First up, if you're having issues with your part of the assignment, or if you have questions about the course material in general, by all means take advantage of your prof's or TA's office hours and hit them up for advice. It was my experience that teachers in college are overjoyed to have students engaged with the coursework. It's only natural, then, that the subject of your group dynamics may come up and you'll have the opportunity to talk about how only 2 people of your 5 person team are seeming to do any work. In fact, this may be an issue you can get advice on. Even if the advice is "yeah, we figured lots of groups would be like this, which is why we really only gave enough for 2 people to do if they're motivated", that is useful information.
You may not get any dispensation at the end of the project even if you've been complaining about this all along, but I will tell you this much: you are far, far more likely to get aid if the professor/TA is/are aware of these issues far in advance than if you drop this on their plate along with your assignment, or worse if you never tell them at all and they have to, say, assume that 5 people did the work over 3 weeks that one college kid could have done in one particularly harrowing weekend, and grade you accordingly.
How to profit from this experience.
Loyalty to your classmates may seem admirable in college but once you have a paying job that is the only difference between you paying your rent next month and going back to live with your parents, you will quickly find that your first loyalty has to be to yourself. You do nobody any favors to prop up a guy who is slacking or, what is worse in my mind (because the conversation is so much harder) a guy who tries but just can't cut it.
In fact, my experience, particularly with Scrum/Agile style smaller groups, is that very often you are constantly liasing with people who are not technically savvy, don't really understand what it is that you're doing for them, and just want results. Often these people are either signing your paycheck directly or else they report directly to the person who does. If you don't tell them that in your 5 person team (for instance), 3 people are goofing off or don't know what they're doing, they will assume that all 5 of you are slacking when you miss deadlines. Or, in the best case scenario, they'll be in no position whatsoever to recognize you for your 70 hour weeks making up for the work of the guys who aren't pulling their weight. Those people need to be cut so that management can hire (presumably) more competent people in their place or else, if things are too far along already, understand that they should expect a 2-person team level of results, not a 5-person team's.
It's not an easy position to be in, but software development isn't necessarily easy, and the need to be a bit on the ruthless side only increases as you get out of college.
And I know I said this before but it deserves re-mentioning: I know it sucks to feel that you have to shoulder the load here, but look at any situation where people are slacking as an opportunity rather than a bad thing. If you're in groups of 5, your prof has designed the assignment to provide you with a (relatively) small amount of work to do and a (relatively) small amount of feedback in return for your work. If you "have to" do 100% of a job you were only expected to do 20% of, you're getting 5 times as much of an opportunity to gain what athletes refer to as "muscle memory" - the innate knowledge of how to do what it is that you do that you really only get by doing it - not to mention 5 times as much face time with the prof and/or TA when the assignment is finished. You should pity these folks, not be angry at them.