3 ms·

Every re-write I’ve ever seen or been a part of, has either failed or taken way longer and a lot more effort than initially projected. Changing something is de

by nico 4y ago

Every re-write I’ve ever seen or been a part of, has either failed or taken way longer and a lot more effort than initially projected. Changing something is definitely not riskier, especially if you have tests and real users who are actively providing feedback as well as showing the edge cases. You can also focus on changing only the things that need changing, instead of having to redo everything just to change some things. A re-write also delays everything, since current users will probably not get any updates nor access to new features until the re-write can provide a good alternative to the existing system. Oh well, I guess since it’s a side project for them, the learning and fun will be more important than providing a good experience to their users.

robinhood 4y ago
Author of Chandler here. While rewriting the project is extremely fun and definitely a very good learning curve for us, we actually care A LOT about our users. I believe Chandler is much, much better to use than the current crappy Monica. It's easier, better UI and UX wise, and have way better features. And we are working our asses off to provide an API, and an importer to let you import your data so you won't lose anything. I agree, while we are rewriting the software, we don't have time to do anything on the current codebase, except bug fixes here and there. It's a price we have to pay unfortunately. So why do we rewrite? It's simple - the current codebase is old, and complex, and not fun to work on. We have merged things in the codebase from the community that we shouldn't have merge. The DB structure is old fashioned, and not flexible, so migrations would be a nightmare to do. I'm not saying it's not possible to improve the current codebase, but... that would be an actual job, and we don't want it to feel like a job.
- Shank 4y ago
  > We have merged things in the codebase from the community that we shouldn't have merge. Do you have examples of what these features are/were? And, sort of tangentially, do you recommend actually setting up Monica in 2022 or waiting until Chandler to try the stack?
beachy 4y ago
> Every re-write I’ve ever seen or been a part of, has either failed or taken way longer and a lot more effort than initially projected. On the face of it what you say is true, but I've seen (and I'm sure many have seen) situations where the codebase was so bad - or the underlying technologies so ancient - that a rewrite was the only practical way to get things back on track again. Did the rewrite take way longer than initially projected? Yes. Was it a lot more effort than initially projected? Yes. Was it painful medicine that nonetheless left the business in a better place? Yes.
- selcuka 4y ago
  > Did the rewrite take way longer than initially projected? Yes. > Was it a lot more effort than initially projected? Yes. > Was it painful medicine that nonetheless left the business in a better place? Yes. You make it sound like this is a net positive, but that is meaningless when you are not comparing it with the alternative: > Would refactoring it be faster? Yes > Would it require less effort? Yes > Would it still leave the business in a better place? Yes I don't think one can ever justify a rewrite unless (1) the code is trivial to implement, or (2) it is covered with extensive unit and system testing, or (3) the technologies used are no longer available/supported, there is no upgrade path, and a new language/framework is absolutely necessary.
tomcam 4y ago
They’re doing it for fun.

by nico 4y ago

robinhood 4y ago

Author of Chandler here. While rewriting the project is extremely fun and definitely a very good learning curve for us, we actually care A LOT about our users. I believe Chandler is much, much better to use than the current crappy Monica. It's easier, better UI and UX wise, and have way better features. And we are working our asses off to provide an API, and an importer to let you import your data so you won't lose anything. I agree, while we are rewriting the software, we don't have time to do anything on the current codebase, except bug fixes here and there. It's a price we have to pay unfortunately. So why do we rewrite? It's simple - the current codebase is old, and complex, and not fun to work on. We have merged things in the codebase from the community that we shouldn't have merge. The DB structure is old fashioned, and not flexible, so migrations would be a nightmare to do. I'm not saying it's not possible to improve the current codebase, but... that would be an actual job, and we don't want it to feel like a job.

Shank 4y ago
> We have merged things in the codebase from the community that we shouldn't have merge. Do you have examples of what these features are/were? And, sort of tangentially, do you recommend actually setting up Monica in 2022 or waiting until Chandler to try the stack?

beachy 4y ago

> Every re-write I’ve ever seen or been a part of, has either failed or taken way longer and a lot more effort than initially projected. On the face of it what you say is true, but I've seen (and I'm sure many have seen) situations where the codebase was so bad - or the underlying technologies so ancient - that a rewrite was the only practical way to get things back on track again. Did the rewrite take way longer than initially projected? Yes. Was it a lot more effort than initially projected? Yes. Was it painful medicine that nonetheless left the business in a better place? Yes.

selcuka 4y ago
> Did the rewrite take way longer than initially projected? Yes. > Was it a lot more effort than initially projected? Yes. > Was it painful medicine that nonetheless left the business in a better place? Yes. You make it sound like this is a net positive, but that is meaningless when you are not comparing it with the alternative: > Would refactoring it be faster? Yes > Would it require less effort? Yes > Would it still leave the business in a better place? Yes I don't think one can ever justify a rewrite unless (1) the code is trivial to implement, or (2) it is covered with extensive unit and system testing, or (3) the technologies used are no longer available/supported, there is no upgrade path, and a new language/framework is absolutely necessary.

tomcam 4y ago

They’re doing it for fun.