Discussion on: What "accepted truth" in software development do you find questionable?

phantas0s profile image
Matthieu Cneude

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...

ben profile image
Ben Halpern Author

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.

v6 profile image
🦄N B🛡

// , 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."

Sacrificial Architecture Sketch Example