4 ms·
Right on. This is related to "the big rewrite" that kills a lot of projects. Time and usage makes code value go up. Even if it’s written in an old framework tha
by jokull 14y ago
Right on. This is related to "the big rewrite" that kills a lot of projects. Time and usage makes code value go up. Even if it’s written in an old framework that you wouldn’t use today, uses urllib instead of requests. Just ignore the urge and move on (for now).
I’ve recently worked on an old project (www.oath.is), dusted it and launched it as an app. It was a Django project and my urge was to rewrite the whole thing so I could use SQLAlchemy and Flask which I had picked up in the meantime. On the frontend I immediately wanted to rewrite everything in CoffeeScript and Backbone.js. But I resisted it and managed to spend my time adding features, a new design and unit tests and launched in like a week. After launching I had some extra time to rewrite the jQuery-spagetthi, which paved the way for some more advanced client side features without becoming a horrible mess. So I guess you have to make that decision multiple times over the lifetime of a project. But yes, holding off the urge is a good practise.
- LeonidBugaev 14y agoThanks! Exactly what i mean.
- deleted 14y ago[deleted]
- j-kidd 14y agoWhen the existing code base is at least functional, then of course, a big rewrite is not warranted. However, some of us are not as lucky. The situation is often such that the existing code base is full of bugs that it can cause a ton of support requests from the users, or even crash and bring down the production server. In such situation, you can choose to firefight all days and have no time left to implement new stuffs, or choose to rewrite. Not using the latest hippiest libraries is really the least of my problem.
- jokull 14y agoAgreed. When it comes to code that’s "not exactly how I would have done it" but _also_ bug ridden I think it’s an easy decision.