Does anyone know why they are rewriting the whole thing? The github page doesn't mention the reasoning behind the decision
> [...] Monica is an old code base now. Old in the sense that it’s 7 years old and it has been touched by hundred of contributors. There are some concepts in the code that we let through, because we either didn’t know any better back then or because we didn’t want to piss off contributors, that we don’t want anymore. The project has way too many dependencies, and maintaining the code has become harder than it was before. Changing something is riskier, and takes more time. Also, we’ve seen how people use Monica, what they want to do with it, and the current code limits us way too much if we want to support what people want to use Monica for. Finally, Monica is still a side project for us. We are extremely passionate about it, and we want to also have fun building it. And the current version wasn’t that fun.
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.
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?
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.
> 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.
If you took away a dollar for every software engineer who I heard say that, and actually followed through, I'd still be a rich man.