4 ms·
The central hypothesis is that developers are not writing tests since they prefer bugs popping up on production instead of during development, and it seems quit
by The_Colonel 3y ago
The central hypothesis is that developers are not writing tests since they prefer bugs popping up on production instead of during development, and it seems quite absurd. I've been in many dev teams in many companies, but haven't seen incentives to be that much messed up.
One reason this doesn't make much sense is that this requires hoping that the bugs pass QA. If QA finds those bugs, sends them back to dev, then they still have to fix that + very significant time overhead of this round trip which doesn't make it "worth it".
- CSMastermind 3y agoI mean I've seen it happen with unrealistic stakeholders. Business forces the team to make a false commitment to a specific ship date with a specific set of features. It's obvious that the team can't hit that mark but telling the stakeholders that will just result in them refusing to budge and telling you that you need to come up with a plan to make it happen. Eventually it's easier to just agree with them and do your best than waste even more time arguing with them. Eventually you fail to ship or you ship a buggy mess. The software engineers know the code quality is shit but they don't have time to think or set anything up.
- pylua 3y agoThat is called fraud.
- deleted 3y ago[deleted]
- thowaway91234 3y agoIt’s either more time or less features. Less testing is non-negotiable.
- harimau777 3y agoDevelopers generally don't have the power to make that decision.
- thowaway91234 3y agoNot with that attitude.
- The_Colonel 3y agoYes, this is a common scenario for sure. But it's always "we don't write tests because there's no time" and not "we don't write tests since they might reveal bugs, and we don't want that" as the article claims.
- pseudalopex 3y agoThe article said developers don't want to find bugs because of time pressure. But it didn't suggest fixing the time pressure.
- biql 3y agoSo they lie about estimates because they afraid to miss their chance to delivery buggy mess. But doesn't it do more harm to the reputation in the long term?
- SpicyLemonZest 3y agoThe QA model you're describing isn't universal. In most of my roles there hasn't been any sort of separate QA team that stands between the dev team's code and production. So if you have a small enough set of customers that you can be confident they won't hit certain categories of bugs, or won't care too much if they do... it's tempting, and I've seen it done on occasion.
- The_Colonel 3y agoYes, that's somewhat common, esp. in smaller companies. But the article's thesis still doesn't hold up since in that case it's the dev team which is given blame for the prod bugs. Dev team never prefers for the bugs to pop up in prod as opposed to during dev/QA. (accepting low impact bugs is something different which IMHO the article did not write about)
- SpicyLemonZest 3y agoIsn't accepting low impact bugs exactly what you accomplish by skimping on testing? "I know there may be some issues lurking here, but the blame for customers finding them will be less than the blame for missing this deadline, so I'm not going to go looking for them." I've seen multiple teams where the incentives are structured that way.
- The_Colonel 3y agoYou can't evaluate the impact of the bug if you haven't found it. Without testing, you're letting all sorts of bugs into production - both low impact and catastrophic data destruction bugs.
- harimau777 3y agoThere's a difference between the dev team being blamed versus an individual developer.