Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Follow the wormhole through a path of communities !webdev@programming.dev
good article and I appreciate this isn't the point, but on a personal level I feel like both at once is pretty bad.
Generally you can have something fast or have something stable and you're always striking that balance. Sucking at both at the same time should be a red flag.
Fast, Good, Cheap. Pick two. Most people pick fast and cheap.
Should you invest in software quality?
For 95% of companies, the answer is: No.
This is just wrong. Software quality does matter and this question makes it sound like a binary answer. But it is not. The correct question is how much should you invest.
Maybe software quality doesn't matter that much to your company, but if the cost of improving the quality is a small amount you would be stupid not to invest. But then there might be something else that would cost you a lot to improve the quality only a little bit, then it might not be worthwhile.
Everything is a trade-off, there are very few binary answers like this article they are responding to suggests.
I feel like this is only true of internal or enterprise software where switching is expensive. For business to consumer, the impact of bugs can cause a company to go under or at least become a zombie. For any type of company, the thread of a competitor is high and can cause your company to stagnant and slowly go under or bleed and rapidly go under.
There is a real impact to a high amount of bugs, it just doesn't happen in one quarter. It happens over years and results in higher stress foe the developers. A stagnating company doesn't hire. It doesn't give raises and slashes benefits. A lot of terrible things happen before a company goes under. We can watch Twitter speed running this.
Faster does matter in many cases.
The authors of the original article and the response may have a bit of survivorship bias, and haven't seen companies fail because they fell behind, but that definitely happens. Every company/product that I've worked on (before my current company) is now dead. 90% of everything fails. Companies/products fail (maybe slowly, but eventually) when they are compared against other companies in a similar space that can deliver more features more quickly. And don't forget that things like performance and scalability are "features" here.
Similarly, doing "More" also matters in many cases, and more requires working faster. Having quality (in the critical areas) allows you to work faster. Automated tests are faster than manual tests, but aren't needed everywhere.
I have to say I mostly agree about bugs, though. Most bugs don't really matter.
