Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
Success on a short term doesn't depend on the quality of your code.
On the long term, it's another story. If the application grow, the technical debt will increase, at the end you will have a mess full of bug which will be difficult to refactor.
Rewriting will be your only (costly) solution.
It depends of your business, what you build, if you want a lot of features and for how long the product should work correctly...
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
// , Now here's an "accepted truth" that bears discussion, even from the storied heights of Thoughtworks.
Rewriting an application from scratch has a business purpose, and scaling is a feature, like any feature, subject to "feature creep".
"You're sitting in a meeting, contemplating the code that your team has been working on for the last couple of years. You've come to the decision that the best thing you can do now is to throw away all that code, and rebuild on a totally new architecture. How does that make you feel about that doomed code, about the time you spent working on it, about the decisions you made all that time ago?
For many people throwing away a code base is a sign of failure, perhaps understandable given the inherent exploratory nature of software development, but still failure.
But often the best code you can write now is code you'll discard in a couple of years time."
I like this a lot, and it also tells the story of dev.to well. Early on I knew growing this thing was not about writing perfect code or even having the perfect product, it was about finding the market, having a process, and a plan.
These days, shipping code and squashing bugs is so much more important than it was before. We sort of "earned" the right to be able to focus on the code.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Success on a short term doesn't depend on the quality of your code.
On the long term, it's another story. If the application grow, the technical debt will increase, at the end you will have a mess full of bug which will be difficult to refactor.
Rewriting will be your only (costly) solution.
It depends of your business, what you build, if you want a lot of features and for how long the product should work correctly...
// , Now here's an "accepted truth" that bears discussion, even from the storied heights of Thoughtworks.
Rewriting an application from scratch has a business purpose, and scaling is a feature, like any feature, subject to "feature creep".
martinfowler.com/bliki/Sacrificial...
I like this a lot, and it also tells the story of dev.to well. Early on I knew growing this thing was not about writing perfect code or even having the perfect product, it was about finding the market, having a process, and a plan.
These days, shipping code and squashing bugs is so much more important than it was before. We sort of "earned" the right to be able to focus on the code.