Several responses come to mind here:

1. Unless you're working for a very unusual startup, your time would be better spent writing new code rather than refactoring existing code.

2. You speak of experience as though it's a bad thing. It's possible that your boss knows what he's doing.

3. Ultimately, he's the boss. If you don't like his code and he doesn't like your suggestions, either quit or be fired.

How the the HN community deal with these situations?

I think the usual solution here is to quit and start our own companies where we don't have to put up with a boss we don't like. :-)

I understand you want to emphasize business value and short-term returns but barring refactoring is taking it too far. Smart refactoring will pay off immediately by giving you faster turnaround for new features. And fast turnaround is a startup's edge.

I don't refactor for refactoring's sake but I do refactor every time I would benefit right away from the change. It also makes programming more interesting. Once lousy code is refactored, I can go back to solving the right problems and stop fighting with it.

There have been times I've been tempted to refactor something at Justin.TV, but most of the time it would be wasted effort:

- Sometimes you refactor a feature only to discover people aren't using it very much, and you should just scrap it.

- Other times you arrive at beautiful code and then find it needs to be discarded and completely rewritten in order to scale. If your traffic is growing exponentially, you'll find this happening a lot, no matter how hard you try to avoid it. Figuring out in advance what bottlenecks you're going to hit is often very difficult.

I think the right approach is to just write the best code you can up-front, and live with the mistakes you make. They're minor in comparison to all the other challenges a startup faces.

If his employer coded the first iteration, he may have a better understanding of the problem space and not care if unimportant parts of the back end are sloppy. Or he may need to maintain and debug it himself, in which case refactoring is hurting the business and possibly introducing new bugs.

Those are all perfectly good reasons for development to happen HIS way. I would be really irritated if I hired someone to HELP me they started refactoring stuff instead of following my lead on what are priorities and teaching me in areas where they felt I was weak.

It sounds as if the latent issues here are power and compensation. If it is really about design approaches, try to make the system more modular and take care of building one of the modules from scratch yourself. Your employer is more likely to hand down additional responsibility once you've proven your approach in a restricted area.

2. Experience can be a bad thing, depending on how one relies on it. It depends on whether tone relies on rote memorization and verbatim application of things learned by experience, or whether one spends time analyzing what one has learned to understand when what was learned is applicable. It is quite possible that BigCanOfTuna's complaint is legit, that his boss writes code that requires a lot of additional work and attention. Or it could be he is refactoring because of trivial stylistic things, or just to refactor. I don't know, but I'd like to give him the benefit of the doubt until he provides reason for me to believe he's just wasting time and trying to get his boss's hackles up.

3. And ultimately, you sometimes have to ask whether loyalty to your boss or the success of the company is more important, because these are not always mutually achievable goals. I may be reading too much into this, but you seem to be advocating a monochromatic, obey or leave, line of thinking.

At BigCo, it wouldn't be disastrous if you followed bad direction from a boss. You would be trading an insignificant amount of financial damage for political stability and security. I would still have a hard time doing this and would probably be quite demoralized at an employer that demanded it, but I can at least understand others aligning their priorities this way.

At a startup, unwavering loyalty to one's boss can potentially do much more damage, and deciding between financial success and political security isn't so easy, when forced to pick one or the other. The decision can become even harder when one has bought into the vision of the company, and doesn't view what they do as just a job to pay the bills; they might not be prepared to leave just to avoid a struggle. This may sound hopelessly idealistic; so be it.

Ultimately I don't know what BigCanOfTuna's workplace and boss are like, what his priorities and goals are, and whether his complaints are legit. I do think he deserves more than a cursory dismissal as just another whiny kid who has to get his way.

In my current employment, there are many procedural deficiencies as well as technical weaknesses. But one thing that really is done right is that every piece of code that is merged into the source base is peer reviewed before it is committed. I'm a strong technical member of the team, and when I started I thought quite a bit of myself. Even so, I wrote things which were potentially confusing to my teammates. Not confusing because they are incapable of understanding, but just not having the sort of clarity which would make later maintenance easier for whoever would be tasked with it.

When I got some hard questions in code reviews I felt a bit defensive at first, but once I swallowed my pride (tastes like crow!) and realized that I really am working with talented teammates who want us all to succeed, something clicked. I was teaching others new techniques and idioms, and they were teaching me about teamwork and the importance of writing for other humans as well as myself and the computer. I do sometimes end up doing major structural refactoring of existing code, but there's always both a good business and technical reason for it. I will say that I put in my own taste and style, but there's nothing wrong with that so long as everyone can understand it.

In your situation, try hard to focus on the human element here instead of just the technical element. Have some respect for the people you work with - you should all be bringing a variety of experiences and knowledge to the table. I find it hard to believe that your boss is just trapped in the past and can't understand modern web programming. The fact that he chose Ruby and Rails for this effort indicates to me that he really is open to new ideas and opportunities. Hey, it's not CGI! You certainly have an opportunity to teach here, but you also might have an opportunity to learn something. Try to sit down and have an ego-free conversation about what's going on and see if you can find a deeper reason. Especially in a small startup, resentment and defensiveness can only undermine your collective ability to succeed. You need every strength that you can call upon in such an environment.

Second, stop blaming him. You're working for him, so obviously he has done some things right and deserves some respect. If you understand something he doesn't, it's your responsibility to explain and educate. If he is "very defensive" then perhaps you are bringing issues up in too confrontational a way.

Finally, be patient. Find some code that could be improved with better adherence to Ruby style, work up a changelist that cleans it up, and politely send it to your boss suggesting that you think this style has advantages, would he mind if you fixed it up? Show him how your style has advantages, point by point, and over time you will earn respect.

... and I think you could probably do with hearing his point of view too.

How many other developers are on this team with you and your boss? Maybe you can get them to stand up and say something too.

Maybe you can get together with your team and do peer reviews once a week. Try reaching out to your boss about a function/module you have written that you know needs improvement and seek his opinions on what could be done. You have to start thinking of him as a peer who is trying to help create a successful business and not as an antagonist to beautiful code.

Your code might be pretty, but if beautifying code takes the place of bug fixing and adding features needed to sell a product or service, it doesn't matter.

The point behind tip #7 was to advocate having a single person in charge of editing a component, to avoid two people making changes to the design and confusing one another. The point wasn't to suggest a total lack of caring about the other developer's work.

This smells very much of political fence building, and an overly zealous drive to strictly segment responsibility.

I think the other great benefit is that each person can afford to become an expert in their areas, rather than each person becoming merely competent at everything. I think 3 people who are each experts at 3 different things is more powerful than 3 people who are merely competent at the same 9 things.

Let him run/test the web app or QUIT

Option-1: LET HIM RUN/test the webapp. When errors pop he'll surely come to you. Then explain the right way to him and don't tell him anything more than what he needs to know about the error. This is peaceful and will make your boss more happy that he has a guy who's capable of doing stuff. Days later you'll be called the hero who could do things the right way (yeah like Hancock coming thru the door and not breaking a wall to get in). I chose this. So now whenever there's anything wrong they call me for help even to this day long after the project is over.

Option-2: QUIT. There's no way you can work with these guys if you can't convince them.

I would suggest choosing the first option. Means a lot professionally.

1. Do you believe what the startup is doing is worthwhile? How much of what keeps you there is just a need for a job, and how much is due to you wanting this job in particular?

2. Does his code function correctly? Is it overly fragile? Has it proved to be a maintainability problem in the past? Have others complained about your boss's coding style and defensiveness? If so, what action have they taken?

3. Have others commented on how you approach your boss in these instances? Do you seem overly abrasive? Do you stand your ground when he disagrees, or do you give in as soon as he does? If the latter, do you think you would face severe consequences if you did stand your ground?

Lots of questions, but narrowing down what is important to you will help me and others give you better advice.

2. (Prepare to) Move on. If your boss is truly holding things back, staying will increase your frustration while limiting your development. Been there, done that.