27

I have a problem with my teammates. Long story short: We are three students working at a project for a competition. The project consists of 2 separate applications: one for Windows (that I develop) and one for Android (my colleagues are responsible for developing it). Our code bases will never intersect, the apps will communicate via third party tools.

The problem is as follows: I have some experience working in teams as I made an internship at a big company last year, and I try to enforce some coding standards for our code. I also set up a git repository / wiki / collaboration software that we can use to push code / write ideas, document protocols and so on, but it seems that I am the only one that uses these tools.

I tried to tell them that writing quality code and documenting every step will benefit us in the long run, but they don't seem to see the advantage of it. Also I was thinking to add some integration tests but from what I can see, as long as they don't use current tools to make their life easier, I don't think I can convince them the usefulness of integration tests.

Most of the peer's code resides on their computers, they don't share a common code base and as I found out, they integrated their pieces by meeting and sharing code via usb stick.

My question is: am I too harsh on this matter? Do I enforce some absurd rules? Keep in mind that this is a small project, the requirements are very clear(I created documents specifying what should the applications do), three skilled developers could do this in 3-4 days, so they might not see the added complexity of writing quality code as long as their current method just works.

Is there any way that I can show them the benefit of documenting code, using git and so on?

|improve this question
  • 37
    Perhaps they see it as overkill for a "one week app"? Perhaps it's because of "how" you try to convince them? What's their side of the story? Their opinion didn't even come up in your post, yet listening and understanding is IMHO more important than using this or that tool. ...or perhaps they simply don't care for the scope of the project? Bringing change requires communication, skill and patience. – dagnelies Feb 19 '13 at 8:14
  • 2
    That is what project managers are for. There must be some authority to decide. "Trying to convince" may take forever. – SChepurin Feb 19 '13 at 9:48
  • @arnaud I talked to them about this issue, but they simply don't care. They wrote some documentation but the most part is done by me. Also one of them pushed some changes to our git repository after I requested a code review, but 1 week passed since then. – razvanp Feb 19 '13 at 10:51
  • 7
    Introducing new practises and new tools delays things to start with, and produces speed improvements later. What's the timescale on the competition? – MarkJ Feb 19 '13 at 12:42
  • 1
    Did you introduce them to all of you described one at a time, or made an infodump? If it's the latter, there's your problem potentially - you may have overwhelmed them. This is a classic neophyte error: you know the advantages, but you can't assume they will realize those advantages immediately. You need to start slow, with the most useful thing first. – mikołak Feb 19 '13 at 14:37
42

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.

|improve this answer
  • 3
    Good answer; starting with something easy to use and that they probably already know will be much easier than force them to read documentation. Besides, Dropbox works wonders on anyone unfamiliar with versioning. – DistantEcho Feb 19 '13 at 9:23
  • 2
    I use github with success in a two-man project. We don't use wiki because we don't need to yet, but we use issues and the other github godness. – caarlos0 Feb 21 '13 at 19:35
22

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.

|improve this answer
  • 8
    It would help the OP if you left a comment stating why you downvoted. – Gustav Bertram Feb 19 '13 at 8:00
10

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.

|improve this answer
  • Yes, it would take some experienced developers 3-4 days to finish the project if they work full time, but we have homeworks, courses we must go, days when we are not in the mood for coding - so I specified a deadline of approx. one month. Unfortunately I didn't care to setup some tools to track the total time we worked on a specific feature so I can't reliably tell you total working hours so far for us. Also keep in mind that we plan to continue working on the application after the competitions finishes. – razvanp Feb 19 '13 at 10:45
  • Please see my edit. – superM Feb 19 '13 at 10:57
9

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
|improve this answer
  • Invaluable answer! – Vorac Feb 25 '13 at 13:55
4

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.

|improve this answer
  • I'm not actually convinced that SVN is massively easier to use than git. On windows, I'd advocate Mercurial/TortoiseHG. – penguat Feb 19 '13 at 11:35
  • True. In my experience of SVN and GIT I have found SVN easier to explain to those new to the concept of versioning. – David 'the bald ginger' Feb 19 '13 at 11:43
2

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.
|improve this answer
-1

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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.