re: What "accepted truth" in software development do you find questionable? VIEW POST


That "high quality code" or "fully featured software" is gonna make the product successful / viral.

I highly believe that a poor software can be very successful if the team know how to "sell" the product.

By "sell" I mean:

  • Marketing the product.

  • Convincing other people to use it.

  • Letting the community talk about it.


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

"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



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.

Code of Conduct Report abuse