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.

  • 3
    What about coming up with an agreed coding style guidelines and a code review process? Avoid any contentious issues, just put in enough in the standard that you can both agree to it.
    – Brandin
    Commented May 14, 2015 at 8:56
  • 25
    Fourth option (if it's under a permissive license): fork the code and continue working on your own. Commented May 14, 2015 at 13:54
  • 4
    How is the code licensed? Can you fork it and continue on with somebody else?
    – Jaydee
    Commented May 14, 2015 at 15:03
  • 14
    As @enderland mentions in his answer, there is an absolutely massive red flag in what you wrote: "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." If you can get away from this, do so. Anybody truly worth working with will have the humility to accept that sometimes they will get things wrong. Commented May 14, 2015 at 17:20
  • 3
    No matter what you decide, the 10k lines of code are not lost: think of what you learned from writing them; think of the pleasure you had during the time coding; and, applying what you have learned in a (forced) third/fourth/n+1th iteration might even make it better than the current version. Besides if you know what to write 10k lines of code, you can write 10k lines in a relatively short time; often it's the knowing what to write to make things work is what takes most time. Commented May 14, 2015 at 19:02

11 Answers 11


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.

  • 1
    Thank you for your reply. I am accomplishing the purpose of having fun (when not infighting) and learning. Weather any money is to be made is a completely different story. He does help with accomplishing my goals, however I believe I could still accomplish them on my own, he helps with motivation. The game is a great example of feature creep, I honestly have no idea when it can ship. My partner has been trying to push for a change from 2D to 3D for months now, I refuse since we have already long exceeded our scope. Commented May 14, 2015 at 20:38
  • 1
    I would be willing to drop the project, if it was just my own it would have been dropped months ago. My motivating factor to continue is having someone else to work with, even if the infighting makes me question that some days. The only thing holding me back from abandoning it is a friendship like connection with him outside of coding, I would rather avoid tossing that with the project. Of course this is not a very logic-based explanation, since their are personal feelings involved it really fogs up my decision-making capabilities. Commented May 14, 2015 at 20:39
  • 1
    the quickest way to lose a friend is to work with them as equals!
    – user7519
    Commented May 14, 2015 at 21:06

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.

  • Thank you Gnasher, I do see #2 periodically, though we have no actual schedule so I'm not sure how valid of a response that is. I am going to sleep on this and see what I'm thinking in the A.M. this needs a lot of deliberation before making a decision. Commented May 14, 2015 at 9:21
  • 1
    "If it is that situation, run away." -- and just in general, if you can't reach close to consensus what your goals are then you can't co-operate with someone. Sounds like he won't consent to you changing "his" code, no matter the reason. Commented May 14, 2015 at 15:14
  • Well, it seems that time pressure is not the reason to refuse changes.
    – gnasher729
    Commented May 14, 2015 at 18:03
  • 1
    This is a great answer. You can't force someone to change their ways! However, it sounds like there's a lot of time and effort put into the project on his end as well as yours. My thinking may be that he may not want to change his code because he doesn't understand the way that you think it should be done. It's either that or he's pigheaded, but if it IS that he doesn't understand it, try to keep in mind that he may be frustrated and think that you're "talking down" to him, even though you mean very well. My advice is try to talk it over with him when you both are up to it.
    – zfrisch
    Commented May 14, 2015 at 21:01
  • ^+ It's easy to become offended by someone when you start out at the same level and they surpass you in skill. I'm not saying that is for sure the case, but it certainly sounds like it may have something to do with it.
    – zfrisch
    Commented May 14, 2015 at 21:03

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.

  • 2
    Thank you for the reply. Funny that you mention your first point. He is trying to find and bring in a novice programmer that he can teach to help with the project. I could only expect this to turn out horribly if there where two people following the same style of hack and forget. I like the second option, make it, ship it, and then leave it. Issue I might run into is that we are part-way though making an LLC so that we have a name to ship our game under. Both of use will have a 50% share of course. However, I could just finish it and then move on. The project is large, that could be a while. Commented May 14, 2015 at 7:53
  • 20
    You do not under any circumstances want to enter a legally binding business relationship with a person like that.
    – gnasher729
    Commented May 14, 2015 at 8:25
  • 3
    @douglasg14b bring in a junior to teach.. poor kid. Suggest you bring in an experienced guy "as he would get up to speed much faster and help finish the product". Set your sights on a finish line - or do you both intend to work on this hobby forever and ever and ever? (seen that happen, until it gets cancelled)
    – gbjbaanb
    Commented May 14, 2015 at 9:00
  • I plan on finishing it, definitely. Though I do believe it was far too large a project to tackle as our first. It started out as a simple design, it was not supposed to anywhere near the scale it is now. The boundary of our scope is constantly getting pushed with feature creep by my partner, I am partially to blame for that because I allow it to happen and even agree with some features. The scope is to the point that if left alone we are probably looking at completion within a year. Thankfully with how I've programmed it, parts can easily be taken out and put into other projects later on. Commented May 14, 2015 at 9:13
  • 4
    Think of the code as belonging to the project, not to you. If you have joint ownership of the product, you can reuse all of the code for your next project. If you have no idea who owns what, then have that discussion now. Good luck.
    – gbjbaanb
    Commented May 14, 2015 at 9:18

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.


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.

  • 15
    This falls under the whole "technical debt" argument though, right? When you write that new feature (or modify an existing one), is it taking three times as long as long and producing ten times as many bugs as it would have if you'd kept up with your refactoring? If so, then maybe skipping the refactoring was a false economy. Commented May 14, 2015 at 12:02
  • 1
    You would think so, but I've worked in a lot of successful companies and I (almost) never see refactoring at high priority. My conclusion is that it simply dosnt pay off.
    – Ewan
    Commented May 14, 2015 at 12:07
  • That's fair enough and I'm sure there's a range of opinions on this, just seems like not addressing that one way or the other is a significant omission from the answer. Also I may be wrong but reading between the lines in the question, I think the bad code the OP is worried about may be way worse than the kind of code you're thinking about. Commented May 14, 2015 at 12:10
  • heh, yup! but also it sounds like the cost of making the changes is very high. In my answer I try to give the objective 'are you in this for the money?' answer, plus my subjective view of where the balance of probability lies
    – Ewan
    Commented May 14, 2015 at 12:13
  • 1
    This is reasonable in some cases, but if someone's "working code" is causing another person to spend 2x as much time on their code or integrating systems together or future work, it no longer is a simple "ship vs not-ship" decision. Plenty of large-scale projects die because they don't make decisions to do it right rather than fast.
    – enderland
    Commented May 14, 2015 at 14:53

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.


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.


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

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.


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.
  • 3
    The "last 10%" takes a lot lot longer if 90% of the code is rubbish :-(
    – gnasher729
    Commented May 14, 2015 at 18:05

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.

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