Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

For developers under pressure, it’s better for bugs to be found in production

amazingcto.com

Post reply on HN
Print view View original

51–60 of 81 posts

Re: For developers under pressure, it’s better for bugs to be found in production

#51

Post by SpicyLemonZest »

The_Colonel wrote: post #40
SpicyLemonZest wrote: post #26

Earlier quoted context omitted.

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.

Re: For developers under pressure, it’s better for bugs to be found in production

#52

Post by biql »

CSMastermind wrote: post #23
The_Colonel wrote: post #19

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 the…

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 you…

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?

Re: For developers under pressure, it’s better for bugs to be found in production

#53

Post by renke1 »

jackblemming wrote: post #7

Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.

The worst thing is how often developers almost fatalistically accept that testing sucks. I don't blame them though because improving the test infrastructure has little short-term business value or so they say.

Re: For developers under pressure, it’s better for bugs to be found in production

#54

Post by flashback2199 »

Dudester230602 wrote: post #30
jackblemming wrote: post #7

Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.

There are two kinds of developers: A - puts a brand new project on CV and moves on before go-live. B - stays behind to handle going-live issues and maintain. Guess which kind sees pay growth and promotions?

I would be freaked out building a career on top of a pile of things I don't know how to do

Re: For developers under pressure, it’s better for bugs to be found in production

#55

Post by harimau777 »

The_Colonel wrote: post #40
SpicyLemonZest wrote: post #26

Earlier quoted context omitted.

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)

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

Re: For developers under pressure, it’s better for bugs to be found in production

#56

Post by The_Colonel »

SpicyLemonZest wrote: post #51
The_Colonel wrote: post #40

Earlier quoted context omitted.

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.

Re: For developers under pressure, it’s better for bugs to be found in production

#57

Post by [deleted] »

pylua wrote: post #34
CSMastermind wrote: post #23

Earlier quoted context omitted.

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 you…

That is called fraud.

[deleted]

Re: For developers under pressure, it’s better for bugs to be found in production

#58

Post by __turbobrew__ »

jackblemming wrote: post #7

Developer's dont write tests if writing tests is hard. Simple as that. If writing tests is hard because you never invested in setting up a good test infrastructure with helpful utilities, you fucked up. If writing tests is hard because your architecture is a cluster fuck of mixed responsibilities, you fucked up.

Some things cannot be tested. I work in distributed systems a lot and you can unit/integration test simple functionality, but there is nothing which can test how your system will behave in prod outside of just trying it out.

I find having really good metrics and a tight development cycle allows for quickly iterating on distributed systems problems. Obviously the best situation is to have all of the above: unit tests, integration tests, and a tight development cycle in prod.

If I had to pick one because I am time constrained, I would choose testing in prod with good metrics which is maybe what the article is getting at.

Re: For developers under pressure, it’s better for bugs to be found in production

#59

Post by harimau777 »

thowaway91234 wrote: post #31
CSMastermind wrote: post #23

Earlier quoted context omitted.

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 you…

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

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

Re: For developers under pressure, it’s better for bugs to be found in production

#60

Post by orwin »

Justsignedup wrote: post #2

I found that a suite of useful tests speed up my development by a lot. Tests that test services that do interesting thing in my code. I find that I can get 90% of my work done without ever firing up a web browser. It's cool to know that by the time you hit up the ui the code already works perfectly and I spent less time coding than otherwise. So idk what this article is pointing out. Tests for test sake is probably t…

I don't think you're getting the point (you might be in a small, or in a great team).

Tests are great for the codebase, for stability, for onboarding. But for devs who have management/exec pressure, and especially if the team is 'agile', they will slow your sprint, discover edge cases or bugs you never put in your cards and ultimately 'slow down' initial development, and if your company is especially bad, you'll get performance reviews. If you let the edge case/bug happen in prod, it'll take more time to correct it than if you caught it prior to that, you might have to modify an loop or a data structure and introduce more bugs, but at least the software was delivered in time, and you'll get paid for that time spent correcting those bug if you're a contractor.

Post reply on HN