Ask HN: technical cofounder won't use version control and dismisses refactoring
I have a technical cofounder who refuses to use version control and who is strongly discouraging me from redesigning and refactoring bloated multi-purpose objects. My efforts to broach these subjects are greeted with an angrily and aggressively uttered, "WHY?" and "that's in the category of 'if it ain't broke, don't fix it.'" This is to say nothing of introducing tests (some agreement there, at least in principle) or anything as ambitious as continuous integration. I'm limping along and am inclined to fork the project (my components are in version control anyway). What do you do in the face of implacable intransigence?
4 comments
Somebody near you might be saying; "Co-founder keeps droning on about development buzzwords while I am still trying to bang out a minimum viable product. Time for structure when we have our first hire."
The truth might be somewhere in between but worrying about bloated code while at an early stage must just be counter-productive. You might find something to add rather than something to maintain.
The truth might be somewhere in between but worrying about bloated code while at an early stage must just be counter-productive. You might find something to add rather than something to maintain.
Sure, I'm just as capable of seeing things from another point of view as anyone [perhaps this is the voice of Dunning-Kruger]. I have to say that this perspective is limiting and is exacerbated by my co-founder's somewhat desperate financial straits. I have been adding features--the best I can do is revise code as I go.
The point about development buzzwords is well taken--I use them with some misgivings. I would like my co-founder to educate himself on some of them, however, instead of barking. Software development has advanced in the last 30 years.
My "droning" is confined to a question here. I don't believe I deserve angry, aggressive and peremptory behavior from an excitable person who seems to have anger management issues and delusions of grandeur about an app. What he does have is drive.
However, I find that adding features requires considerably more work than it would have been otherwise. It was a struggle to advance over every little point: use non-UI tasks for network operations lest you get an exception, etc. Also, I'm in the position of having to do merges since he refuses to use version control. Anyway it is a problem to work with one's hands tied--it takes me somewhat less work for me to implement features than my cofounder, even in the face of impediments that I find unnecessary impediments that would be straightforward enough to rectify--if only I could. This tends to perpetuate unfortunate practices.
The point about development buzzwords is well taken--I use them with some misgivings. I would like my co-founder to educate himself on some of them, however, instead of barking. Software development has advanced in the last 30 years.
My "droning" is confined to a question here. I don't believe I deserve angry, aggressive and peremptory behavior from an excitable person who seems to have anger management issues and delusions of grandeur about an app. What he does have is drive.
However, I find that adding features requires considerably more work than it would have been otherwise. It was a struggle to advance over every little point: use non-UI tasks for network operations lest you get an exception, etc. Also, I'm in the position of having to do merges since he refuses to use version control. Anyway it is a problem to work with one's hands tied--it takes me somewhat less work for me to implement features than my cofounder, even in the face of impediments that I find unnecessary impediments that would be straightforward enough to rectify--if only I could. This tends to perpetuate unfortunate practices.
refuses to use version control
It sounds like this person is used to working alone. If the parts you're working on are completely separate, that might be okay. If you're both technical and both working on the same parts, it seems like the repeated breaking of the code would make your argument for you.
strongly discouraging me from redesigning and refactoring bloated multi-purpose objects
Are you launched? Unless this is the critical bottle neck that's preventing further development, there are a lot of people who would agree with him.
What do you do in the face of implacable intransigence?
It sounds like the bigger problem you're facing is being able to successfully argue with each other. That's what you have to figure out.
PG recommends having different cofounders be masters of different domains. Where they come together, you need certain core values you agree upon and to be able to explicitly argue why or why not a particular position supports those values. It also helps to give some level of deference to the person who's actually going to be doing the work.
I'm limping along and am inclined to fork the project
Always an option, and a decision better made earlier rather than later. Someone who was worth trying as a cofounder is worth going through some pain to learn how to constructively argue with. But nothing else will make up for not learning how to do it.
It sounds like this person is used to working alone. If the parts you're working on are completely separate, that might be okay. If you're both technical and both working on the same parts, it seems like the repeated breaking of the code would make your argument for you.
strongly discouraging me from redesigning and refactoring bloated multi-purpose objects
Are you launched? Unless this is the critical bottle neck that's preventing further development, there are a lot of people who would agree with him.
What do you do in the face of implacable intransigence?
It sounds like the bigger problem you're facing is being able to successfully argue with each other. That's what you have to figure out.
PG recommends having different cofounders be masters of different domains. Where they come together, you need certain core values you agree upon and to be able to explicitly argue why or why not a particular position supports those values. It also helps to give some level of deference to the person who's actually going to be doing the work.
I'm limping along and am inclined to fork the project
Always an option, and a decision better made earlier rather than later. Someone who was worth trying as a cofounder is worth going through some pain to learn how to constructively argue with. But nothing else will make up for not learning how to do it.
It sounds like the bigger problem you're facing is being able to successfully argue with each other. That's what you have to figure out.
I have gotten better at it. I find arguing and this aggressive attachment to ideas that are obviously half-baked tiresome. My strategy in some cases has been to wait weeks for the bad ideas to prove themselves unworkable in practice, rather than argue. Deflecting an aggressive, argumentative and often gratuitously rude style takes energy.
Not launched, still, but I dislike repressing an instinct to improve. If it has taken me years to get to this point (we have tried other projects that have failed--this one seems to be succeeding, partly because I have managed to learn how to negotiate with my co-founder, at least to a point), I wonder about anyone else who might join the project.
I have gotten better at it. I find arguing and this aggressive attachment to ideas that are obviously half-baked tiresome. My strategy in some cases has been to wait weeks for the bad ideas to prove themselves unworkable in practice, rather than argue. Deflecting an aggressive, argumentative and often gratuitously rude style takes energy.
Not launched, still, but I dislike repressing an instinct to improve. If it has taken me years to get to this point (we have tried other projects that have failed--this one seems to be succeeding, partly because I have managed to learn how to negotiate with my co-founder, at least to a point), I wonder about anyone else who might join the project.
It's obvious this person doesn't share the same values as you. You need to ask yourself, "Why is this person my cofounder?"
If you don't see eye to eye, now in the beginning, you're going to continue to have disagreements in the future.
If you don't see eye to eye, now in the beginning, you're going to continue to have disagreements in the future.
A refusal to use version control is a big red flag. Version control makes sense in all but the absolutely smallest one-man project because it protects you from your own mistakes.
He's just totally off base.
The portions of the project that are exclusively mine are under version control. I may have to do version control for both of us. Perhaps if he sees the advantages or if it saves him from trouble, he might be motivated to use it, at least minimally (we're talking about learning git init, git add and git commit, essentially!).