Hacker News Reader

> We've done two other releases in the past month and both required a day of troubleshooting to fix issues.

I feel you, it's especially frustrating when your product has such fragile and bespoke testing that things break on a regular basis. Then, us devs have to spend valuable time just troubleshooting.

View on HN

Maybe I misunderstand, but if a product breaks regularly under "fragile and bespoke" testing, won't it break just as often, and probably more often, under robust and comprehensive testing? And if the product fails tests, who better to "just" troubleshoot the problems than the developers? (Perhaps you mean things break after nominal testing and subsequent release, but that's just shifting the time when the issues are detected -- the product still has the issues either way. And if the issues will adversely and/or significantly affect the customer, I imagine one's employer would prefer that you set aside your non-troubleshooting valuable time and fix the issues.)

I think the difference here is that with robust and comprehensive testing, it's immediately obvious when and where things break. Compared to a codebase with no testing, or fragile testing, where things break and you not only have to spend time fixing something, you also have to spend time finding what is even broken in the first place. That's where the frustration is, at least for me.

Reply on news.ycombinator.com