3 ms·

My feeling is that rewrites simply don't scale well. To make them work you need resources, good planning and motivation from everyone involved. As the number o

My feeling is that rewrites simply don't scale well. To make them work you need resources, good planning and motivation from everyone involved. As the number of people increase the probability that any of them made a mistake estimating how long it will take or how well their part will run explodes. That's why refactor tends to work better, rewrite with a scope. I worked at a company were we build small embedded devices (EM dataloggers). I was supposed to take an existing code base shared by several products and modify it to build a new one. The code was beyond ugly. As an example: delay_ms(5) Would yield a 5 milliseconds delay, as long as you weren't in a variety of modes, the GPRS connection wasn't hang up, and GPS had a lock. It was painful to think about it, let alone work with it. I convinced everyone that a total rewrite was necessary, and then I let everyone keep working on the old code base while I worked on the new one to add the basic functionalities. Then we started to move product by product, adding the "extras" each device required. Now the new products are built with that skeleton, and refactors are way less scary and faster, and can be made across devices easily (one of the improvements is that "business" logic has automated testing now). To this day I'm convinced that the only reason that could be made is because we started with the new product, and then moved upwards. Trying to build a new ecosystem for all of them would have failed hard.

commandlinefan 7y ago
> rewrites simply don't scale well. I learned early on that rewriting a codebase is a lose-lose proposition: I’ll never suggest or recommend it again. Not because I don’t think it’s ever a good idea, but because it can only go wrong. If everything happens perfectly without a single hiccup or surprise, you’re still right back “where you started from” from the perspective of management. I worked on a massive rewrite porting a C++-based codebase to Java. The rewrite was actually suggested by “the business” because they were having trouble finding C++ developers and they noticed that Java developers were easier to come by. I was actually hired because I had a strong background in both, so I jumped right tin. I was too young and too naive to realize how backstabbing, conniving, and treacherous business people can be: I actually ended up being blamed for every surprise that came up during the rewrite process.
thrower123 7y ago
The biggest problem with rewrites is that you need someone who understands how the old system works, and why it works that way. Sometimes there are good reasons for why something is a mess, that were the result of long iterations over customer requirements. And sometimes things are just a mess, because. If you are walking into a codebase cold, you don't know which is which, without doing a lot of archeology - assuming, of course, that more than potsherds of that train of cognition is left buried in the commit messages, JIRA tickets, and email archives you have access to.

commandlinefan 7y ago

> rewrites simply don't scale well. I learned early on that rewriting a codebase is a lose-lose proposition: I’ll never suggest or recommend it again. Not because I don’t think it’s ever a good idea, but because it can only go wrong. If everything happens perfectly without a single hiccup or surprise, you’re still right back “where you started from” from the perspective of management. I worked on a massive rewrite porting a C++-based codebase to Java. The rewrite was actually suggested by “the business” because they were having trouble finding C++ developers and they noticed that Java developers were easier to come by. I was actually hired because I had a strong background in both, so I jumped right tin. I was too young and too naive to realize how backstabbing, conniving, and treacherous business people can be: I actually ended up being blamed for every surprise that came up during the rewrite process.

thrower123 7y ago

The biggest problem with rewrites is that you need someone who understands how the old system works, and why it works that way. Sometimes there are good reasons for why something is a mess, that were the result of long iterations over customer requirements. And sometimes things are just a mess, because. If you are walking into a codebase cold, you don't know which is which, without doing a lot of archeology - assuming, of course, that more than potsherds of that train of cognition is left buried in the commit messages, JIRA tickets, and email archives you have access to.