How do you all work in programmer teams?

[camelCase]

Hey, I've mentioned this before but I'll do it again; I'm on an internship now and the experience is.. different.. I haven't worked on a team before; much less, with other programmers.

My team is made up of only interns with many mentors for us to turn to, should we seek help; there are a total of 7 teams of interns. However, most of the mentors have been away for their own conferences and businesses for a while now..

So, I'm turning to this forum for advise.

I work with one other programmer on my team and we have trouble communicating properly. He's an awesome dude and all but when it comes to work, that is when we start butting heads.

So, I think the problem is that we can't convey how the classes go together (because we, ourselves, don't clearly know, either; warning sign) at times and, at others, we just have opposing views on how a certain thing *should* be done; he also likes to just hack code together and call it "done" and it's not for a throwaway prototype, either!

After butting heads, he usually gives in; this might seem pretty good but it worries me =/ I'm pretty sure he's cursing me in his sleep right now.

Also, he knows a lot of math and algorithms (I like learning about them from him) but he sucks at coding; he, like, knows the theory and stuff but he hasn't been applying the stuff he knows, I guess. I don't want to sound conceited at all but that's just my personal opinion.

I guess I'd just like to know how you guys avoid conflicts among programmers and convey ideas so that all the programmers know what the final product will be and what happens when two programmers have very different views on something.
------------------
Note: You don't have to read the bottom part.
I guess "telling" it won't help and I should "show".

Recently, we realized that Unity's GUI is reallllllyyyy buggy on Android tablets and that we had to do some touchscreen stuff that Unity didn't support.

So, we had some discussion and agreed that he'd handle it (he knows more math & algorithms). Then, we discussed this "TouchScreenManager" class' methods and what messages it'd send (onTouchBegin(), onTouch() and onTouchEnd()).

After an hour or so, he said he was done and I looked at the result; he had the touch screen manager send only onTouchBegin() messages. He said that the other two were handled by the two other classes he created: Draggable & Button.

So, basically, we can only have these touch methods get called and stuff only if a game object has the draggable or button script; so not generic. He and I got into a very heated argument.

My view was that this TouchScreenManager class should handle sending messages to whatever game objects it hits with the ray cast. Why? Because that's its job, I can't think of any other way to word it. It detects when an object is touched and when the touch has ended; nothing else should do it. That way, only one ray cast is made every update for detecting object touches.

His way required one ray cast PER object EACH update to check if it is still being touched.

His view was that my way would make dragging and clicking difficult to detect because there would be an overload of information; you would know precisely when an object is touched (or not) when you might not want to treat it as so.

I tried to tell him that it doesn't matter to the TouchScreenManager; if an object is touched and wants to behave like it isn't, that is purely game-logic and has nothing to do with a generic TouchScreenManager. The more information the TouchScreenManager gives, the better, because we can work with more information and ignore the ones we don't want easily. It's harder to work with less information and hacking more code together to get more information.

He nodded his head but has yet to listen to me; I guess this is one of those times where he doesn't give in; his stupid TouchScreenManager still relies on two other classes to work =.=

I'm just ignoring this fact for now.. Until he breaks the game, sigh.
But it's so difficult.. knowing that I really have to rely on one other component to work when it isn't necessary at all.
------------
I feel like this has become a rant thread rather than a help-me thread =/
(I really do want advise, though; this shouldn't have to continue much longer)

 

[s3rius]

Needless to say I think you're right.

I'm currently working on a 5(?)-man project on creating a social network website for a university.
They pulled me in for the Java back-end. So I'm basically one of their code guys.

The way we make sure that no-one says "Ok, will do it." and then returns to us with an implementation that's vastly different from what I thought of is that:

http://i.imgur.com/i2CkR.png

We define the entire inferface (functions, classes, what they do) beforehand. Everyone has to stick to the plan after that.

For the planning itself:
I think you need a boss. Someone who has the final say on things. Everyone is allowed to voice their concerns (and they should be taken seriously and discussed) but in the end it's for him to decide.

In our group I'm basically the boss for coding. In the final days of planning I had to reject an entire UML layout for our logic part because I decided that it would not integrate well into our web-app and database (the girl who did the work was furious when she heard that xD).

People have different opinions and some find it hard to follow the plan of someone else (like me! I like being boss xD) but it's no use to let him have his way half of the time while you decide the rest.
One of you should have the last say, the other one should have to respect that.

Both of you could probably take that position. I think that your decision about the TouchScreen issue was the right one, but that doesn't mean that his wouldn't work.
Both of you would face problems at some point that come up because of your design decisions.

If you have several components that are very much seperated from each other you can take turns in being the boss.
For example, I was the king of the logic realm. The web-app was handled by someone else. The web-dude and I only had to agree on the few links between our systems.

IF you have the time and excess brain power you can also try out things.
You say it would take too many raycasts. Well, make a simple implementation of both systems and see if the workload would be too high for your desired specs. If the program is lagging like a bauss.. you know what to do

 

[camelCase]

Hmm..
It would be easier to just let one of us have the final say and stuff but we really have the same rank =x

I took your UML diagram advice and spent a whole day getting our existing code base to UML and discussed his touch class.. Guess he isn't budging but I'll take it as a learning experience, I guess. (He did spend many days on it..)

But I did find a few ugly things in our code because of the diagrams! Like certain classes having unrelated responsibilities for no good reason.. and inconsistent naming conventions.. He and I couldn't shrug it off because the ugliness was so evident in the diagrams xD
Guess that's why they're useful =x

My producer suggested selling my points more gently. Like, "Your touchscreen manager works, and that is great, but I need certain features that aren't there; could you add it for me?" and other stuff similar to that.

Producer said to not care about the efficiency of code for now =/
(So his weird thingy stays; I'll be like a lawyer and rely on binding contracts from now on where code is concerned ><)

 

[s3rius]

Heh, "posted a moment ago". Dat timing!

Producer said to not care about the efficiency of code for now =/

BURN THE HERETIC! (ノಠ益ಠ)ノ彡┻━┻

I'm one of the sort who writes ++i instead of i++ because it might be faster :/

 

[camelCase]

We're using C# with all its garbage collection =/
Efficient code pretty much went out the window over there (imo).

While I'm coding in C++, I'm careful about where I allocate and deallocate memory; with C#, I just pray I don't have any references to an object I intend to not use =/

Plus, we've got Unity and all its weird behaviour; it's great for making games and all but, most of the time, I'm just cursing it for random reasons.

Off the top of my head, today, I cursed that Unity doesn't support namespaces; which I wanted to use with the "internal" keyword to workaround the fact that C# doesn't have the "friend" keyword (as far as I know) =/

I'm one of the sort who writes ++i instead of i++ because it might be faster :/

I didn't know the difference; so I used to write i++; then, one day I found out.. And now, I write ++i, too xD
---
Huh.. I guess simply rephrasing my views to be more.. friendly did help..

I still hate that he sits right beside me and pokes me (yes, he literally uses his index finger and pokes me) every time he encounters a brick wall, though..
But he doesn't know that =P

 

[seph ir oth]

In time, when working in programming groups, it is most wise to spend more time planning rather than programming, assuming you are all seasoned programmers. It is more important to formulate a solid structure for whatever application you are making (I'd say around 25% of actual work time is programming, IF THAT).

Test cases are your friends! Design documents are your friends! UML is superbly useful!

I've become a huge fan of gantt charts for programming teams. You can allot time for error and such. It's a good practice to stick to one:

http://en.wikipedia.org/wiki/Gantt_chart

EDIT: So I actually read the full rant of the OP (lol) and I'm just gonna say this now: Unity is a crutch that shouldn't be relied on for serious games. It's cute for somethin basic, but if you wanna go above and beyond, it's better to whip up a homebrew with libraries of your choosing.

Not sure if you guys have the time for that though. Depends what you're working on.

Can't say I ever tried to make a mobile "game" on Unity. I gotta say though, I was mighty impressed when my friend and colleague showed me Flash CS5's capabilities to make mobile apps & games as well as external includes that optimizes the graphics. I shat my pants when I learned that a mobile device could confidently use pixel-perfect collision for nearly everything through Flash.

Perhaps you could leave the GUI to Flash somehow?

 

[camelCase]

Well, we only have 9 weeks to produce the game; a two player, tablet, casual game.
My team's come to the end of week 4. Also, our staff liaison was adamant that we use Unity; they didn't want to rule out the option of porting to other platforms.

So using Flash wasn't an option, unfortunately.

We've been making extremely good progress; I spent 18 hours crunching alone a week ago and wrote the core classes of the game. After that, he couldn't argue because everything worked fine and was there.

I also find it easier to let other people actually touch my code and fiddle with it once I know how the pieces fit; I was really possessive of my code before we had all the core classes ><

However, I will remember the advice given here =)
We've been organizing ourselves through fogbugz, trello, UML and a simple high level technical doc.

Trello works really well as a scrum board!

 

[xPass]

Reading all of these scares me :/
I hate drawing diagrams and so I have a feeling I'm going to regret it big time when my Student Project 1 starts.. next week Q_Q