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

41–50 of 81 posts

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

#41

Post by pseudalopex »

The_Colonel wrote: post #35
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…

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.

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

#43

Post by aranchelk »

> Tests are bad for developers. That is why. They can only detect bugs. Tests can only tell developers they made a mistake. There is no gain at that moment.

When test-driven development is applicable, it’s so damn nice. If for no other reason, just because it requires so many fewer keystrokes and clicks, just have a process watching for changes and rerunning the test suite. Less chance of developing RSI, it’s good for developers.

I added the caveat “when applicable” because for straight-up UI behaviors it’s not, but the longer I write code, the more I see ways to separate out pure logic from UI and other external effects and I’ve never regretted doing it for reasons including: general reasoning, readability, TDD, future changes, and bug fixes.

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

#44

Post by dickersnoodle »

ajmurmann wrote: post #22
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 were good tech leadership matters. Leadership must push back on product to make room too build out test infrastructure. Otherwise you'll see individual engineers who do the right thing get punished for it because get aren't delivering tickets.

Word. I work for a reasonably large online retailer that fancies itself a "tech company" and you'd be amazed at the pushback I kept getting for insisting on a proper test infrastructure for their mobile apps - dependency injection for mock API endpoints with captured data, fuzzing to capture UI weaknesses and the like. But no, they need to go fast because... well, because their product/market fit isn't that stable and they're using "data driven" decision making to justify chasing one rabbit after another to try and juice the stock price.

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

#45

Post by xutopia »

gdsdfe wrote: post #4

I'm all for testing but honestly unit tests are the least valuable type of tests out there, I'd rather have an integration test that uses no mocks

I disagree. Testable code tends to make more modular and easier to refactor code. It is easier for someone who is not writing tests to make things way more complex than it needs to be.

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

#46

Post by dickersnoodle »

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…

>> Tests can only tell developers they made a mistake. There is no gain at that moment.

This is the dumbest thing I have seen on HN in a long, long time. Full test coverage supported by good mocks is one of the quickest and most efficient ways to find regressions that I know. Don't discount the value in helping developers see when they've made mistakes, especially when you're rotating junior and mid-level developers on and off your team.

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

#47

Post by add-sub-mul-div »

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.

As an engineer I made myself responsible for quality for my whole career back when I had the freedom to guide my own work. Under agile/scrum I'm too unengaged to care what works in production and don't accept the idea of responsibility without authority and autonomy.

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

#49

Post by ajmurmann »

dickersnoodle wrote: post #44
ajmurmann wrote: post #22

Earlier quoted context omitted.

This is were good tech leadership matters. Leadership must push back on product to make room too build out test infrastructure. Otherwise you'll see individual engineers who do the right thing get punished for it because get aren't delivering tickets.

Word. I work for a reasonably large online retailer that fancies itself a "tech company" and you'd be amazed at the pushback I kept getting for insisting on a proper test infrastructure for their mobile apps - dependency injection for mock API endpoints with captured data, fuzzing to capture UI weaknesses and the like. But no, they need to go fast because... well, because their product/market fit isn't that stable an…

It's also really hard if you don't do it right from day 1. You'll be spending substantial developer time to put things in place and achieve minimal coverage which means the positive results might not materialize till much later. Worse, the positive result might just be slowing down the rot and you'll never be credited by much of the org for things not having gotten worse. Even worse, if you get replaced by a yes-man who stops enforcing testing and clean up, a temporary "boost" will happen. It's all totally broken and it's honestly burning me out about this industry.
Post reply on HN