Hacker News Reader

Comment by The_Colonel | Hacker News Reader

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

View on HN

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

It’s either more time or less features. Less testing is non-negotiable.

Developers generally don't have the power to make that decision.

Not with that attitude.

That is called fraud.

Yes, 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.

The article said developers don't want to find bugs because of time pressure. But it didn't suggest fixing the time pressure.

So 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?

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

Yes, 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)

Isn'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.

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

There's a difference between the dev team being blamed versus an individual developer.

Reply on news.ycombinator.com