Hacker News Reader

Comment by wpietri | Hacker News Reader

I can't find it now, but I remember a story from somebody in the Lean Manufacturing world about a place that was having safety problems, so they appointed somebody Safety Director. This signaled to everybody that safety was that one guy's problem, not theirs. Accidents went up further and stayed up until they got rid of the Safety Directory position and made everybody responsible for safety.

That resonated for me because I've seen that happen in software, that classic pattern where cowboy coders ship garbage to QA. The lowest bug rates I've seen are where everybody cares about quality.

With Facebook, I expect that "Chief of Advertising Integrity" is sort of light a lightning rod. The job is not to solve the problem, it's to take the hits.

View on HN

There are pros and cons of having dedicated teams for work that also has to be accomplished by other teams. For instance, it's not a good idea to skip having a security team using the logic that "other teams will just think its that one teams job." The security team provides expertise and (with cooperative management or other teams) can enact policies that influence the rest of the organization to the benefit of security. That can't happen without a set of people dedicated to thinking about those problems.

For your QA team example, the mistake made in some organizations is explicitly removing testing from developer's responsibilities.

It's a matter of BOTH/AND -- you need to have BOTH central teams responsible for long term health of {safety,privacy,security,testing,etc.} AND hold developers responsible to deliver the recommendations of and use the tools developed by central teams.

Aww, c'mon, tell me that QA/security/accessibility/whatever isn't regarded as a meaningless hoop to be jumped through as quickly and with the least effort possible so that you can get real work done. Ain't nobody got time for that rigamarole.

With EU laws, GDPR and UX fanatics, many have to do the heavy lifting or risk multimillion dollar fines. So it's changing.

In games, QA is taken very seriously. I know with games like Cybepunk people think game developers don't care about QA, but I am sure that is a certain circumstance where they chose to ignore problems. On big games you count on QA for feedback.

If you're shipping buggy and insecure software, you will soon get a whole lot of free time on your hands.

That's why i think devops has some good ideas - you are responsible for the shit you ship. Also developer on calls - if you ship shit that goes down or causes errors, you get woken up in the middle of the night or during your vacation.

I disagree about on call developers. No one should have to be half at work on their time off. Fix the business model so that becomes unnecessary.

there is no model where that becomes unnecessary. If someone who did not create the product is on call, they become the poor sod stuck solving a problem of not their own making.

> half at work on their time off

i mean not constantly. Also if you're on call, you're always paid for doing so regardless of what happens. This talk isn't about compensation, but about the model of work.

There is. You split the team or hire additional engineers in other time zones, such that no one is relied upon to work on their time off. There should always be someone working at all times around the globe, available to support.

I was part of a group that inherited a really buggy service platform, maybe a dozen services, 3 generations of most services still around, no logging, nothing. The previous team had kept some foreign engineers on-call and never taken shifts - and there were daily pages, absurd processes to "fix" things, etc.

In about two weeks of putting engineers on call for their own services, most of the major problems were fixed.

It's easy to write buggy software when you aren't the one who gets called at 2am to fix it. Once you start being responsible for your software, the urge to take shortcuts really evaporates. On the other hand, a team that is not responsible for their output will always cut corners - it's just the way it goes.

There's an easier way to do that. You give them poor performance reviews or fire them if they don't improve.

If you make these things Big Process, each of which requires spreadsheets and certification by high level manager and weeks of delay, etc, then yes, people will think of them as meaningless hoops. If you can avoid dumb red tape then things can go quite well.

In games, when QA reports into the same person managing the product, things run smoothly and everyone remains aligned towards shipping a good product. When it's a separate org that loans people out and has OKRs that don't connect to individual products, they become horrible trolls who are only out to fuck the product up by submitting so many bug reports that it can never be released. Sim with whole-company legal teams ("never ship anything, we might get sued") and shared security ("never run services or we might get hacked") and ops ("never use servers or they might crash"). Alignment is everything.

This story explains why every workplace safety exam I ever took had at least one question similar to "who is responsible for fire/machine/... safety" where the only correct answer was "everyone".

This goes for computer security as well, but in practice without at least a voice in the management security will get axed on every turn because it is seen as all cost without benefit to the company. This is changing slowly, mostly on account of the GDPR, but it is still the prevailing view.

> That resonated for me because I've seen that happen in software, that classic pattern where cowboy coders ship garbage to QA. The lowest bug rates I've seen are where everybody cares about quality.

On the flip side, I get nervous when I hear something akin to "We don't have QA here", sometimes as a matter of pride. Think of those times when you've heard someone snear at "Safety First", but for QA or testing.

Perhaps one ideal would be to promote a "everyone cares about quality" environment whilst still having some people focused specifically on QA.

It’s the plus and minus of specialization. When you have a dedicated QA team it can be harder to hold the devs accountable for the defects QA doesn’t find.

As someone who works in accessibility and interfaces with folks at big companies, I can see how this type of problem would apply in lots of areas.

Sounds like something out of the Silicon Valley TV show.

That's such a funny story, and so predicate. I would love the source to this if it comes to anyones mind!

Reply on news.ycombinator.com