I’m a strong believer in “fix bugs first” - especially in the modern age of “always be deploying” web apps.

(I run a small SaaS product - a micro-SaaS as some call it.)

We’ll stop work on a new feature to fix a newly reported bug, even if it is a minor problem affecting just one person.

Once you have been following a “fix bugs first” approach for a while, the newly discovered bugs tend to be few, and straight forward to reproduce and fix.

This is not necessarily the best approach from a business perspective.

But from the perspective of being proud of what we do, of making high quality software, and treating our customers well, it is a great approach.

Oh, and customers love it when the bug they reported is fixed within hours or days.

▲

ivolimmen 10 hours ago | parent | next [-]

Would love to work on a project with this as a rule but I am working on a project that was build before me with 1.2 million lines of code, 15 years old, really old frameworks; I don't think we could add features if we did this.

	▲	chamomeal 7 hours ago \| parent [-]
		Same. The legacy project that powers all of our revenue-making projects at work is a gargantuan hulking php monster of the worst code I’ve ever seen. A lot of the internal behaviors ARE bugs that have been worked around, and become part of the arbitrary piles of logic that somehow serve customer needs. My own understanding of bugs in general has definitely changed.

▲

stevoski 5 hours ago | parent | prev [-]

I wrote up my thoughts on this into a longer post: https://killthehippo.com/posts/fix-bugs-or-add-new-features