4 ms·

We've just spent half a year moving a legacy* Java app to nodeJS and now some of them want to redo everything in Rails. *: all the original engineers have left

We've just spent half a year moving a legacy* Java app to nodeJS and now some of them want to redo everything in Rails. *: all the original engineers have left.

thehardsphere 9y ago
That sounds bad. Generally, someone at the company should be saying no to these rewrites unless they have a very clear business motivation. Total rewrites easily spiral into being costly disasters, and usually don't solve a customer's problems. If nobody is at least trying to say no to these things, that means your company may have other problems with defining business objectives and fulfilling them. Even if nobody understood the Java app, that itself is not a good enough reason to rewrite it in another stack. Actually, not understanding the current implementation is probably the worst reason to do a rewrite, because the team likely doesn't understand the problem well enough to successfully reimplement the solution. The fact that they did this in nodeJS and now someone is talking about doing it in Rails makes it sound like there weren't strong reasons for choosing nodeJS established up front. It sounds like people are deciding these things based on hype and not actual technical merit, because the "sweet spots" of the three stacks you've mentioned are all quite different. There are good reasons to choose Java, nodeJS, or Rails for any given project, but there are generally not good reasons to bounce between them for the same project. The only case I can think of where that would make sense would be to move from Rails to Java due to scaling issues (e.g. if you are Twitter). I don't think there is much compelling reason to go the other way, unless your legacy Java app is super-dooper legacy like the FactoryFactoryFactoryFactoryFactory stuff people used to write in the early 2000s. Which itself might indicate an entirely different set of problems. I'd bail out if I were you and try to work at a company with better engineers working for it. Even if this job is stable you will become a better engineer by being around better engineers who aren't going to be proposing giant rewrites.

We've just spent half a year moving a legacy* Java app to nodeJS and now some of them want to redo everything in Rails. *: all the original engineers have left.

thehardsphere 9y ago

That sounds bad. Generally, someone at the company should be saying no to these rewrites unless they have a very clear business motivation. Total rewrites easily spiral into being costly disasters, and usually don't solve a customer's problems. If nobody is at least trying to say no to these things, that means your company may have other problems with defining business objectives and fulfilling them. Even if nobody understood the Java app, that itself is not a good enough reason to rewrite it in another stack. Actually, not understanding the current implementation is probably the worst reason to do a rewrite, because the team likely doesn't understand the problem well enough to successfully reimplement the solution. The fact that they did this in nodeJS and now someone is talking about doing it in Rails makes it sound like there weren't strong reasons for choosing nodeJS established up front. It sounds like people are deciding these things based on hype and not actual technical merit, because the "sweet spots" of the three stacks you've mentioned are all quite different. There are good reasons to choose Java, nodeJS, or Rails for any given project, but there are generally not good reasons to bounce between them for the same project. The only case I can think of where that would make sense would be to move from Rails to Java due to scaling issues (e.g. if you are Twitter). I don't think there is much compelling reason to go the other way, unless your legacy Java app is super-dooper legacy like the FactoryFactoryFactoryFactoryFactory stuff people used to write in the early 2000s. Which itself might indicate an entirely different set of problems. I'd bail out if I were you and try to work at a company with better engineers working for it. Even if this job is stable you will become a better engineer by being around better engineers who aren't going to be proposing giant rewrites.