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.
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. :-)