3 ms·

I strongly disagree with your point #1. I understand you want to emphasize business value and short-term returns but barring refactoring is taking it too far.

by matstc 18y ago

I strongly disagree with your point #1. 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.

abstractbill 18y ago
I agree with cperciva's point. 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.
- trevelyan 18y ago
  I also agree. 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.

by matstc 18y ago

abstractbill 18y ago

I agree with cperciva's point. 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.

trevelyan 18y ago
I also agree. 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.