[JoelSutherland]

This is not really the attitude a company should have when they manage benefits:

On the flip side, with so many people contributing code mistakes are bound to happen. That’s normal – after all we’re all just people, and people make mistakes. One thing that I’ve found particularly admirable about our team here is that people own up right away, and strive to fix things as fast as possible. No one wants to ship buggy code, but it happens. The nice thing about working with so many smart and friendly devs though is that you can trust that someone will be there to catch you if you fall and help you fix things.

We've caught and reported 4-5 bugs in production to Zenefits on really basic features. Three of our employees have now been asked to send a screenshot of the dashboard with the JS console open...

[Someone1234]

> 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.

[zmillman]

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.

[eykanal]

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.

[DanBC]

> 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.

[eru]

Give the second line guys a bonus for every error caught, and make the first line guys pay?

[codeonfire]

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.

[russell_h]

> 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.

[gabrielflorit]

This Buzzfeed article corroborates your findings: http://www.buzzfeed.com/williamalden/zenefits-hr-rocket-ship...

Glad my benefits aren't handled by Zenefits.

[hellbanner]

When working for a devshop a while back, one of our programmers discovered a SQL injection by using some non-alphabet characters in their health insurance password...

We informed them. Never checked to see if it was fixed :)