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

71–80 of 81 posts

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

#71

Post by kderbyma »

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…

that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right

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

#72

Post by MoreQARespect »

__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,…

You can get quite close to reality with really good integration tests. There's all sorts of real life scenarios ive hit like flaky networks, email appearance in various clients, etc. that can be integration tested with a bit of creativity but most people wouldnt even think to do it.

The investment in this stuff can be quite high...unless you've got premade tooling for all of this that you can just drop in.

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

#73

Post by MoreQARespect »

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.

You could spend your entire life improving test infrastructure. There's clearly a cut off point where the investment stops making sense but it's hard to know when.

The investment calculation is quite complex and many of the variables require guesses. A lot of returns on automation work are not positive.

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

#74

Post by josephmosby »

We have an alternative path that works for us: get a terrible, ugly, but functional version of the feature up as quickly as possible. Preferably, the uglier the better. Skip the tests for now. Put it behind a feature flag or some other way to "get it into production" without any real users able to see it.

This lets you try the feature out end-to-end. Click buttons that call APIs and see if the right actions occur. Fix all the stuff that breaks when you first try this out.

Then show it to a friendly. Product manager maybe, engineering manager, another developer... whatever. Someone who understands you're just looking for someone to try out this feature with you.

It works now? Great. Put unit and integration tests around it. Make sure that this happy thing you have running won't accidentally break. Now make it pretty. Give it the design product actually asked for. They'll have feedback, which you can now incorporate safely because you have tests.

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

#75

Post by flashback2199 »

anotherhue wrote: post #62
flashback2199 wrote: post #54

Earlier quoted context omitted.

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.

It's a problem of motivation, alright? Now, if I work my ass off and Initech ships a few extra units, I don't see another dime!

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

#76

Post by __turbobrew__ »

MoreQARespect wrote: post #72
__turbobrew__ wrote: post #58

Earlier quoted context omitted.

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

You can get quite close to reality with really good integration tests. There's all sorts of real life scenarios ive hit like flaky networks, email appearance in various clients, etc. that can be integration tested with a bit of creativity but most people wouldnt even think to do it. The investment in this stuff can be quite high...unless you've got premade tooling for all of this that you can just drop in.

Yes, unless you are doing a clean room implementation of paxos or the raft protocol it probably isn’t worth the effort to create harnesses to simulate packet loss, thundering herds, split brain, out of order responses, etc. Even then, if you are writing some distributed synchronization primitives you might be better off with formal proofs than some sort of test harness.

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

#77

Post by thowaway91234 »

harimau777 wrote: post #59
thowaway91234 wrote: post #31

Earlier quoted context omitted.

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.

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

#78

Post by mbrumlow »

kderbyma wrote: post #71
mbrumlow wrote: post #38

Earlier quoted context omitted.

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…

that assumes you have the leeway to take longer. a lot of issues arise when there is an unforeseen deadline and you get just enough time to get out the code with some bugs and then can add tests and refactor afterwards. usually this happens when a critical component suddenly gets sunset and you need to work in a work around temporarily until you can do it right

I am trying to convey it's not about leeway, it's a yes or no. If you are asked can you get this done in 2 days, and you think "yes, but if I skip test", then your answer is "no, you can't get it done in 2 days". You are simply shipping unfinished work.

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

#79

Post by iamnafets »

nine_zeros wrote: post #66
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.

The obvious needle thread here is to not "make" engineers do anything, but hold them accountable to the results the business needs to see. The best teams are composed of empowered, accountable engineers who have the flexibility to do what they're paid to do.

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

#80

Post by iamnafets »

add-sub-mul-div wrote: post #47
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.

Agreed. Scrum, in most cases, robs engineers of the agency they need to deliver maximum value. My teams did better work without it under the condition that the talent was motivated, technically proficient, and had the right incentives.
Post reply on HN