> This is not really the attitude a company should have when they manage benefits
Why exactly? They are talking at the individual employee level, not company wide. The statement above is: "[As an individual developer] it is ok to make mistakes, just own up to them and take responsibility."
They didn't touch on test coverage, integration Vs. unit testing, code reviews, UI automated testing, code quality inspections (both automated and manual), regression testing, external audits, or a whole bunch of other things a company can do to improve the quality of their software over the medium to long term. These exist to help mitigate an individual's errors.
If we take what you said above at face value, you're essentially saying: "It is unacceptable for an individual employee at a company who manages benefits to make mistakes ever period." Which when re-phased like that is patently absurd.
Your anecdotes above may be legitimate reasons to gripe about the quality of Zenefits' software. But these are issues with organisational quality, not individual quality. Individuals can and will make mistakes at any endeavour no matter how mission or life critical, the way organisations detect and resolve these mistakes is what is key to quality, not pretending that people should be mistake free, that's a pipe dream.
I'm pretty understanding of occasional bugs, but Zenefits' site has been one of the most consistently buggy pieces of software I've ever used. Every flow has had broken pieces of UI, incorrect form validation, totally wrong calculations, or some other frustrating flaw.
It's an incredibly useful product (and leagues better than the competition) but when they can't even calculate your 401(k) contribution correctly, imagine what's going on behind the scenes...I'm trusting them with a lot of financial and personal information and it erodes a lot of the trust & confidence I would have in them to see such shoddy work.
The problem isn't with the first part ("it's OK to make mistakes"), it's with the second ("just own up"). When a mistake is made, it's because some part of the benefit coding process failed. I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC. The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.
I really can't speak for the company—it's just a single sentence in a blog post on an otherwise unrelated topic—but I imagine that's what the OP was thinking about.
> I work in an insurance company where 100% of benefits coding changes are put through QC, and then another 25% are put through a second level of QC.
For electronic engineering this is a known fault mode of inspection.
When the first line inspectors are busy they'll shovel stuff theough with less inspection because there's someone else to do so checking. But now that other person is busy, and they'll shovel stuff through because if the first line of inspectors are doing their job properly it should be okay.
So it's interesting to see this not fail in an indistry tha is data driven and cash sensitive.
It'd be interesting to know what the difference is.
Yeah, lets pretend there is a perfect process and also punish people who own up to mistakes. That is stupidly what most companies do: add more process, make developers stand on their heads. The fact is that certain types of logic errors are likely never to be caught by SCA, code reviews, test cases, or anything else. It's just a fact that bugs are going to get through no matter what. It's is far better to have an environment where fault tolerance is built in AND there is no punishment culture for bringing bugs to light. If you rely on process you will get a) people hiding bugs, b) blame culture c) more disasterous failures.
> The costs of screwing this up are pretty high, and will make people pretty mad. You need to have a process where the vast majority of mistakes are caught before they get out the door.
Its interesting to reflect on this statement in the context of Zenefits vs the insurance industry.
Why exactly? They are talking at the individual employee level, not company wide. The statement above is: "[As an individual developer] it is ok to make mistakes, just own up to them and take responsibility."
They didn't touch on test coverage, integration Vs. unit testing, code reviews, UI automated testing, code quality inspections (both automated and manual), regression testing, external audits, or a whole bunch of other things a company can do to improve the quality of their software over the medium to long term. These exist to help mitigate an individual's errors.
If we take what you said above at face value, you're essentially saying: "It is unacceptable for an individual employee at a company who manages benefits to make mistakes ever period." Which when re-phased like that is patently absurd.
Your anecdotes above may be legitimate reasons to gripe about the quality of Zenefits' software. But these are issues with organisational quality, not individual quality. Individuals can and will make mistakes at any endeavour no matter how mission or life critical, the way organisations detect and resolve these mistakes is what is key to quality, not pretending that people should be mistake free, that's a pipe dream.