What factors should influence how I determine when to abandon a small project with a friend? [closed]

Question

I've found myself in a tough spot as of late. Been working on a game with a programming buddy for nearly 8 months now. We both started off as newcomers to programming around August of last year, he is a 2nd year CS student, I'm an IT support tech by trade and am a self-taught programmer with multitudes of books and online subscriptions.

The issue that I've been constantly seeing is that as we write out a chunk of code, it will often be a bit hacked together, have many failings, and if it's a brand new concept to one of us, full of naive solutions. This is fine, we are learning, I expect both of our code to be a bit hacked together on the firs or second pass. The problem presents itself when it comes to actually fixing and refactoring those hacked together behaviors.

My partner will hold onto his freshly cobbled together behavior, blatantly refusing to see any error the moment it starts to work. Claiming near perfection from a piece of structure I can't even try to use even if it had comments and appropriately named methods & fields. No matter how hard I try I just cannot get him to see the glaringly obvious flaws that will prevent any further changes or expansion of the behavior without completely breaking it and everything it's so tightly coupled to they might as well be in the same class. Hacked solutions perpetually stay hacked, poorly thought out designs stay the way they where when first conceived and tested.

I spend as much time babysitting new code as I do writing it myself, I'm a loss of what to do. My partner lost it tonight, and made it clear that no matter what, no matter the benchmark, no matter the common practice, no matter the irrefutable proof, his code will stay the way he first made it. Even if entire books have been written on why you want to avoid doing something, he will refuse to acknowledge their validity claiming it's just someones opinion.

I have a vested interest in our project, however I am not sure if I can continue to work with my partner. I seem to have three options open to me.

• Stop caring about the codebase functioning past the point of compiling, and just deal with trying to maintain and parse behavior that's barely limping along. Hoping that once things start to seriously break he will see that and try to do more than just put a bandaid over the fundamentally flawed design.
• Keep up the endless arguments over issues that have been figured out a decade ago by other much more capable individuals.
• Stop programming on this project, abandoning nearly 10,000 lines of my code and countless hours slaving over design and try and find a new project on my own.

What approach can I take to determine if it is worth continuing on with this project with this person? Or what factors should influence my decision? We have written a lot of code and I do not want to give this up unless necessary.

Answer 1

Shipped, imperfect code is better than perfect code on the whiteboard that never gets shipped.

That being said...

Those of you with more experience, or that have been in similar situations. What did you do? What would you recommend I do?

I would consider the following.

• What is the purpose of this project? Fun? Money? To learn?
  • Are you actually accomplishing this purpose?
• Is this person actually enabling you to better accomplish your goals?
• How close are you to actually shipping?
• Do these issues prevent you from launching? Or are they a matter of personal pride?
• Are there benefits to working with someone on a voluntary basis when it's frustrating?

Stop programming on this project, abandoning nearly 10,000 lines of my code and countless hours slaving over design and try and find a new project on my own

Consider the above, try to think through the additional work required.

You need to figure out your priorities and determine if the issues related to working with this person are worth it. We can't figure this out for you.

My partner lost it tonight, and made it clear that no matter what, no matter the benchmark, no matter the common practice, no matter the irrefutable proof, his code will stay the way he first made it.

You know you don't want to work with this type of person.

You're doing a project like this presumably because you want to learn programming and find elegance in the craft itself.

Answer 2

This may be a cultural thing. In some cultures, admitting that you made a mistake is unheard of, and asking someone to admit to making a mistake is about the rudest thing you can do. If it is that situation, run away.

In my experience with very smart people, if you tell them that something they are doing is less than perfect, they will either (1) give you a correct and easy to understand reason why what they are doing is actually right, (2) tell you that they know it is wrong, but they have no time to fix it because of priorities, or (3) thank you for pointing it out and fix it.

Refusing to learn is about the worst attribute a software developer could have. Leave him to it. Life is too short and precious to waste your time on him.

Answer 3

Possibly the easiest way is to bring someone else into the project - either you're wrong and his codebase is just too clever for you, or you're right and its too clever for everyone. You'll soon find out, and will get backup if it does turn out to be rubbish, convoluted, junior-programmer level code.

On the other hand, a working product is worth any number of years of finely tuned, elegant, clear code. Make the game, ship it, walk away then - leave him to maintain it and do not work on v2.

Answer 4

Here are some ideas even if some of them are mutually exclusive.

• Separate source responsibilities. If you work on Module A and him on Module B you can compete with your different styles. Is he releasing working features often? Does he reach a point where he needs to rewrite his code from scratch? Refactor the code from your modules and do not touch him's,

• Let him do the maintenance of his worst code. If he does it successfully you have avoided an awful task. If he is not able he will feel the pain.

• Consider it from a user or business point of view. In some cases you only need a viable product that google or Microsoft might buy. In other you are launching a product to market and supporting thousand of clients with buggy or hacked code will be hell. Is not the same if your code controls drones with nuclear missiles or makes happy videos for teenagers.

• He does the classes, you do the tests. Refactoring code with tests is easier and safer. This way you won't need to look inside the code just the Junit bar. This assumes that A) you are programming tests, B) your colleague code is testeable. If you find hard to build the tests during the coding phase latter will be worse.

• Go together to training or events. When you do not know the right way is quite natural use the only way you know. Seeing other's code might not solve everything but won't hurt to try.

• Find your complementary strengths. Refactoring can sometimes be fun. If he writes things that at least work you might then do the refactoring. He can do spikes to explore solutions that do not end in production code.

• He might not want to rewrite the code but he might agree to write the new code better. I understand that rewritting is hard, boring and can break things. Grow some islands of quality. This way he will have good examples of how to do things.

• Use the boy scout rule. Do left things untouched unless you need to work on it. If a module is badly written but works and do not need to change leave it like that. If you need to fix a bug or complete a feature improve it a little. After some time the 20% of classes that you change 80% of the time will improve. More islands of quality.

We cannot suggest what is the best solution without knowing both of you. Good luck.

Answer 5

Ok, here is an answer you will probably not like.

Do not 'correct' the code unless it fails to implement the feature.

Here's my reasoning. You are presumably trying to make money. To make money you have to ship completed features quickly. No one is going to pay you more for a 'well coded' computer game.

Most companies have the same problem. Refactor existing code to make it 'better', sometimes even objectively better in terms of speed or reliability OR write new features.

99% of the time they choose to write the new features because the result of simple cost benefit analysis.

Answer 6

I like all of the answers so far. Taking one of the points from enderland's answer:

Are there benefits to working with someone on a voluntary basis when it's frustrating?

I'd like to take this time to plug for the code review stack exchange. It's a wonderful place where you can get your code critiqued by professionals. And honestly, a lot of the code reviews there are hugely helpful to those involved - the askers, the answerers, and those who stumble by and read them. You rarely get such useful reviews in a professional setting(which may just be the case at the places I've worked for whatever reason).

My bit of advice is to post some of your code for review. I wouldn't suggest using it as ammo to prove this guy wrong - I doubt he'll take it to heart - but you can get very useful information both on code you've written and code he's written. I'd recommend submitting the pieces of code that you two fight over the most. In all likelihood, you're both wrong to some degree and you can use the review as a way of getting an objective third party to step in. This will accomplish a few things:

• You can disconnect from the situation's emotional tension.

• You get real-time professional advice. A big boost to what you're learning.

• Someone will tell you you're wrong. Which is good, because anyone who does programming for any length of time is going to hear this. You can handle it poorly like this guy you're working with, or you can learn to deal with it.

I think if you use the code reviews the right way, you have a lot to gain by dealing with this extremely frustrating person. And it's far more interactive than a book or website that says "do this, because it's the right way most of the time".

Similarly, there's the game developer stack exchange. Not so much a place to post code for review, but to ask about concepts/ideas you're struggling with. Again, that place is hugely helpful for all involved.

You may have seen both of these sites before; I just wanted to make sure they're part of your toolset.

Answer 7

It sounds pretty hopeless. I would probably give up and move on if I felt about it as you do; there definitely comes a time to walk away and you may be there.

If you're not ready to walk away yet, you need to find a way to come to better agreement about your process. It sounds like you have coding standards, but not agreed-upon standards. Next time you come to a crossroads, next time you want to monkey with a bit of code and your buddy wants to leave it alone, shoot for a conversation along the following lines:

douglas: I want to change it because X, which is right here in our guidelines.

buddy: It's fine how it is.

douglas: So you're saying we should change the guidelines?

buddy: No, I just think it's fine how it is.

douglas: So what are the guidelines for?

buddy: I don't know - you wrote them.

douglas: What guidelines would you write?

buddy: I wouldn't write guidelines. It's a waste of time.

douglas: So we should just throw away the guidelines and write whatever crap we're thinking at the time?

buddy: This isn't crap.

douglas: Is it perfect? Is it ideal?

buddy: It gets the job done; let's move on to the next feature.

douglas: Is there anything we can agree on, that X is good code and Y is bad code?

buddy: Leave me alone; I just want to code!

Well, that didn't go well, did it? I guess the feeling I have is that you and Buddy want different things. If there's anything you can agree on, great; start from there and build on it. But you can't make him agree to want what you want - any more than you could make yourself want what he seems to want. If you can find that common desire, and come to common agreement from there, maybe you can work together.

douglas: What do you want?

buddy: I just want to code.

douglas: I want to code, too, but I want to feel proud of my code.

buddy: I'm proud of my code.

douglas: Here's a function I'm proud of - what do you think of it?

buddy: Well, it's OK, but you shouldn't recalculate X inside the loop; it's inefficient.

douglas: So are you saying we should always calculate constant values outside loops?

buddy: Well, duh!

douglas: Would you think that ought to be in our guidelines?

buddy: Of course.

douglas: OK, I'll add it to our guidelines, and I'll update my code...

douglas: How is it now?

buddy: Fine.

Now Buddy is contributing to the guidelines (however indirectly), and so he's got a bit of a sense of ownership. Maybe - just maybe - he will start to take them more seriously. I think I'd be inclined to wipe the slate and start over with the guidelines, letting most or all of them come from Buddy at first. Go ahead and write shit code so he feels the need to add to the guidelines; let them come from him. Maybe then he'll start to understand the reason for them.

But if you'd rather give up and move on - that might not be such a bad option either.

Answer 8

Assuming you decide to abandon the project:

• Fork the code and refactor it, using it as a 'before/after' portfolio item
• Since the goal was (mainly or partly) to learn programming and since learning something takes 2-4x as long as doing something you know already, that work is not really wasted.
• 'Sunk cost attachment' (the investment you've already made in a venture before learning it was a bad idea) is one of the most common human errors in decision-making
• To keep the friendship, frame your decision as prioritizing the friendship over coding

Answer 9

tl;dr you should arguably abandon the project.

Without knowing any more about this then you've told us, I'd speculate that the friction you're experiencing is experience-related.

Even though you're not a programmer by profession as an IT pro you've probably learned the hard way about doing things right the first time, your reference to your future self indicates you've screwed him/her over in the past and learned not to.

Your 2nd year CS student, even if quite gifted, probably lacks the perspective of having done that (if you're like me, repeatedly :).

He/she will never really believe in the value of fixing things as you go until he/she has burn scars from failure to do so or is mentored in a culture with exceptional engineering discipline, or both.

This person may be your programming peer, but is not your project peer, so doing this game as a peer project is likely a lost cause. Unless you are prepared to just eat the future cost. Maybe the relationship is valuable enough to you. In that case give hem/her enough rope to hang himself/herself and step in to help clean up the mess when that person is forced to acknowledge the problem.

Otherwise bail and do a project with a peer, or do a mentor/mentee project where that's the dynamic from the outset.

Answer 10

To add additional points to all the great answers:

• How much more effort will it take to finish the project? Note that finishing the "last 10%" takes much much longer than people expect. That includes play testing/tuning, usability fixing, coping with a variety of target platforms, releasing, ... If it's an iOS game, then there's code signing and getting through Apple's review. Honestly, finishing can take as long as the first "90%". And it'll be extra difficult if the code is as bad as you suggest. (Can you start play testing it now?)
• Realistically, how likely is it that people will enjoy your game?
• Beware of the "sunk cost heuristic". Evaluate that 10,000 line-of-code investment in light of the big picture, looking back on a finished product, and without undue optimism.
• Can you keep going if it takes another 3 years? You two have different development styles (not a good team match). It sounds like you're near the end of your patience and if you keep going, it could be difficult to remain friends.

Answer 11

You should just keep doing your code the way you think is right, with comments and such and making a copy of you version of the code (in case he changes your code).

Do not fight, don't get mad, just smile when you see his poor decisions.

Only complain as a user, if it is working don't complain.

Don't give up either, it is important to get used to people that is different from you, that will happen in a real job.