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

31–40 of 81 posts

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

#31

Post by thowaway91234 »

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…

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

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

#32

Post by tdeck »

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.

This is absolutely it. I've worked on multiple projects simultaneously where I wrote great tests on one project and few to no tests on the other. It wasn't the developer that changed, it was that one codebase was designed with testing in mind, while the other was not and was therefore extremely cumbersome to write tests for. That also meant that in the second codebase whole UI flows had no tests, so if I made one tweak to the UI flow I wasn't going to spend a week figuring out how to test it and everything around it.

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

#33

Post by tdeck »

orwin wrote: post #25
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.

Writing tests, if you have to mock everything each time because you can't duplicate the production, isn't really hard. It's long and boring. If I have to ballpark an estimate on a tool/project, I say upfront something like: it'll take me 6 days olus a day for very limited tests, so 7. Twice as much with almost complete coverage. But each time we'll have to improve/refractor, a bit of that time will be recovered. Basi…

It's interesting, I often find the tests take me twice as long as the implementation. 1/6 of the effort would be a dream.

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

#34

Post by pylua »

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…

That is called fraud.

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

#35

Post by The_Colonel »

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…

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.

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

#36

Post by nightowl_games »

"bug fix sprint" sounds like a horrible inefficiency. Is that the goal? Is the goal to constantly weasel more time out of your manager?

That's not my goal. I like delivering high quality stuff to users. I like 'moving the needle'. I like coming up with a plan to produce business value, and doing it. I like getting stuff done.

This article perpetuates the 'developer vs manager' concept which is a ridiculous mindset rooted in primitive human flaws. Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation.

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

#37

Post by qaq »

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?

A

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

#38

Post by mbrumlow »

kapitanjakc wrote: post #27

The real reason I don't write the tests:- Client/ Manager :- When is this going to be ready? Me :- Estimated time for development is n1 days and around n2 days for testing, and depending on the bugs n3 days to fix them. Client/manager :- No no, we don't have time, do it in n1-1 days. And when you ship it with bugs, they have a shocked Pikachu face.

You have to start with test first -- just make them "the task".

Don't give estimates separated by test and features.

New feature at hand? First thing you code is the scaffolding to call or trigger new feature (this may be trivial on some projects, or impossible on others).

So long as you start out that way when asked, how long? The tail end always contains the feature, and they can't say cut it.

I worked at a place once where I was setting up a minimal CI/CD pipeline for the project -- I took the first few weeks to do this. In a meeting I was called out by another engineer that had longer tenure at the company. "Are you working on 'devops' stuff because you don't know how to do the primary objective". I responded with a very long triad of why all this other stuff IS the primary objective, and was never questioned again (by that same engineer anyways). All this to say, part of being an engineer is also to educate fellow engineers on ways of doing things better than status quo. It can be hard, and you can put your self at risk. But it's a choice you have to make for your self, the engineer who cuts corners to make mostly arbitrary deadlines, or the one who build robust software. You don't have to go in 100%, but at least have a leaning to one side or the other and make the better choice when it really matters.

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

#39

Post by berkes »

nightowl_games wrote: post #36

"bug fix sprint" sounds like a horrible inefficiency. Is that the goal? Is the goal to constantly weasel more time out of your manager? That's not my goal. I like delivering high quality stuff to users. I like 'moving the needle'. I like coming up with a plan to produce business value, and doing it. I like getting stuff done. This article perpetuates the 'developer vs manager' concept which is a ridiculous mindset ro…

I think you are arguing exactly what the article argues. That this dev vs manager, and all that comes from it, is bad.

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

#40

Post by The_Colonel »

SpicyLemonZest wrote: post #26
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…

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)
Post reply on HN