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

61–70 of 81 posts

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

#61

Post by l72 »

r0s wrote: post #5

Maybe not perfectly framed, but the point that engineers don't have time to write tests is salient. Minor disagreement with this point though: > Tests can only tell developers they made a mistake. There is no gain at that moment. The value is locating the problem code faster, and that generally can't be done efficiently in production. Outside a testing environment, you rely on logs alone to debug, or if you're more p…

When we have business logic changes or a bug fix, I require our developers to write test cases for the new behavior and commit that. I want to see those test fail in the CI systems. THEN they can implement the changes until the tests pass.

When reviewing, the first thing I do is look at the tests. That is how I make sure developers understood the new requirements. Only after verifying that, so I then do a code review to critique implementation.

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

#62

Post by anotherhue »

flashback2199 wrote: post #54
Dudester230602 wrote: post #30

Earlier quoted context omitted.

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

Not management material.

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

#63

Post by orwin »

tdeck wrote: post #33
orwin wrote: post #25

Earlier quoted context omitted.

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.

I was unclear, I apologize. The 'quick testing' isn't really testing imho. (basically no unit test, small integration tests with the data I could steal from the prod DB). It takes around 20% of the time (or 1/6 in my example taken from my last project). The 80% coverage that include mocking and unit test double that time.

I am always extremely clear with my estimates being just that, estimates, and that a complete testing double dev time. Most of the time I'm told 'we don't care right now', but on some projects, management accept longer dev time for more stability and less bugs (we build internal tools).

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

#64

Post by GreenAlien »

I worked on a project where we handled the results of an API call. For testing we mocked the various API call results. When we went live, we discovered they had changed the results of the API call. All the testing was worthless.

Still, I hate having bugs in my code and strive to make sure they don't happen. Still I have had managers release my code when I tell them there are active bugs being worked on.

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

#65

Post by nine_zeros »

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…

> Fix your relationships with your colleagues and work together to make quality stuff. No deception. Only cooperation.

Can you tell this to my manager? Especially the "no deception" part?

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

#66

Post by nine_zeros »

iamnafets wrote: post #12

Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization.

> Sounds like the problem is engineers aren't accountable for quality. Rather than prescribing a solution, these leaders should make sure incentives are correct in their organization.

A low effort management practice is to make engineers move fast at the expense of quality.

An even lower effort practice is to then turn around and hold engineers accountable for the choices made by management in the first place.

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

#68

Post by ysavir »

renke1 wrote: post #53
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.

The irony is that is absolutely does have business value. Unfortunately, it's easier to quantify the problems you've had on prod than the problems you've prevented on prod, so people tend to measure against the former.

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

#69

Post by lamontcg »

mbrumlow wrote: post #38
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 o…

Yeah +1 on not even talking to anyone in management about tests.

I've never talked about solving problems like that, always just talked about the time to fix the bug / implement the feature, and test were implicitly part of that. I've also never had a manager start micromanaging me over how many tests I was writing. That's always been my own judgment call to make.

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

#70

Post by manmal »

__turbobrew__ wrote: post #58
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,…

To give an example: You can unit test your OBD response parser all you like, at some point you have to actually get in the car and see what gibberish the OBD adapter spews at your app, what timeouts it needs, how reliable it is, etc
Post reply on HN