My question is: am I too harsh on this matter?

You can lead a horse to water, but you can’t make him drink.

It’s hard to say whether you’re “too harsh,” but it may be unrealistic to expect your teammates to adopt all the infrastructure that you’re hoping for. And truly, if the team is working well together, using a wiki to communicate between three people is probably overkill.

Scale back your expectations and look for ways to achieve some of your goals without requiring them to start using tools that they don’t know. If they don’t know how to use git, they’re probably not going to get a lot of benefit from it in any case. However, you still want to make sure that all code is backed up in case of a hard drive failure or other catastrophe, so ask them to periodically copy their project folder to a Google Drive, Dropbox, or similar online file sharing service. Make sure you do the same.

My attitude is that if you can learn to do these things on small projects, you’ll be prepared when big projects come along.

If they follow good development practice with this project, they will have code to showcase to future employers, and they will have experience that would make them valuable as employees.

If you want more material for convincing them, I would refer to the Pragmatic Programmer, or Code Complete.

On the other hand, consider cutting them some slack. If the project is a proof-of-concept that is getting binned right after the competition, then you should consider just letting them do as they like. They might be struggling just to write the code in the first place, without the mental overhead of good practices.

I’m afraid the rules you described aren’t basic at all.

The easiest task IMO is convincing your teammates to use some coding standards. And a simple way to achieve this is to show them the same code snippet once well-formatted and then poorly-styled, ask them to read the code, understand what it does and let them judge themselves.

What comes to using a git repository, this can be a pain to novices. When I was working in a team of 3 people on an Android project, we had a lot of trouble with our version control system at first. So I expect your teammates will have the trouble too.

You’ve mentioned that it would take 3-4 days for experienced developer to finish the project (I assume that it would take your team 2-3 times as long). This is a very short period of time, so the argument that using new tools will help in the long run simply won’t work.

What you can do is make short and simple demos to show how those tools are used. Cover the most basic functions at first, sit by their side and help them use the tools. Be prepared to do all the tasks like configuring the git, creating the wiki page structure, etc.

Edit: In reply to the comment, I think that establishing clear tasks, estimations and deadlines and keeping track of the time spent is more important than using git or similar tools. If you plan to work on the application later, it is very important to keep a track what is already done and how long each feature took. So I suggest you start from task management, and then proceed to the tools you want to use.

I actually like Joel Spolsky’s own thoughts on it, as he laid out in Getting Things Done When You’re Only a Grunt. To summarize:

1. Just do it – Write makefiles, create a daily build server etc.
2. Nobody uses source control or bug databases? Start using them yourself. If someone reports a bug against your work, ask them politely to use the bug database to report bugs to you so you can keep track of them; otherwise you won’t be able to keep them straight in your head and fix them. On any non-trivial project, there’ll be a situation that’s only solvable with source control: use source control for the code by yourself and swoop heroically in to save the day when such a situation occurs. Once this happens a few times, they’ll become convinced
3. Create a Pocket of Excellence – Do the right things for yourself: speccing, scheduling etc. Since this doesn’t seem like a work project, it doesn’t look like you can take this advice all the way, since you can’t hire new team members who believe in your message
4. Become Invaluable – Demonstrate that you’re a great contributor to cement your influence in the team. Otherwise you run the risk of becoming known as a person who values process and tools over results

Documentation, Wiki, versioning software, methodologies etc are experiences and lessons learned over time; working of several projects and probably over several teams. And it usually sticks with those already employed or who take their industry seriously.
They are students, so their interests are probably limited short of what happens in the future. 🙂

But to try and answer your question:

If you are in a team with them you would need to apply what you think is important in a way that benefits their interests. As an example : Should they complain about their code breaking a lot when the usb-share it? Then perhaps give them a simple (non complicated) way of using SVN (rather than git) as a versioning tool.

I also agree with the comment from arnaud.

You saw the benefit of all these tools when you were working with them and that is how you saw value in them and why you understand their use. If your team mates do not see a value added in how they currently do things, then they will not apply it. And the sad thing is this even counts for teams made of people with any level of experience.

The approach has problems:

1. Your approach is not symmetric. Your other team members needs to change, but you’re not learning their good practices. Enforcing rules in situation like this is difficult. Better approach would be to collect good rules and practices from all members of the team and then everyone just reads the resulting document.

2. Learning is difficult. Other people’s rules just do not make sense because those rules do not have the logical structure your programmers are expecting. Enforcing rules that do not make sense is not useful activity.

3. Everyone learned different things. It’s natural that programmers coming from different backgrounds have learned different things. Their strengths are different, and styles of writing code different. The tools they use are different. Enforcing one set of rules/tools/styles are going to be nightmare because the limitations are losing the strength those developers have spent years learning.
4. Change takes time. While the person who invented the rules you’re enforcing have pretty easy time following the rules, everyone else is suffering, and spending time learning the new rules. This is one reason why everyone on the team should be able to change the rules.
5. Choosing tools/coding conventions or styles for a whole team is difficult activity. It can only be done slowly over time, testing what stuff works and what is not working. Giving a team 2 weeks to start following 50 rules is not going to work.

I’ve found this very problem at university. Many people simply are not willing to learn a different (and maybe more professional approach) way of working.

I’f you have systems in place however and explain how to use the system then many people are willing to give it a try. I also think that repositories are very under used tools and people will commonly just use a something like dropbox.