It's about what broke, not who broke it • Hacker News Board

Re: It's about what broke, not who broke it

#51

Post by iovrthoughtthis » Wed, Mar 28, 2018, 9:43 AM UTC

thinkloop wrote: post #38

itronitron wrote: post #34

Earlier quoted context omitted.

code rots, whether it is being used in production or not, and should be consistently refactored and updated to accommodate the current status quo

So much so that I don't think "refactoring" should even be a concept - that's what coding is. Every feature, bug fix or change should take into account the new relationships and structure of the model. Leaving refactoring for later is ignoring the fundamental required task of coding.

Eh, refactoring is distinct from feature developement, prototyping and testing.

They are different modes of thought.

Re: It's about what broke, not who broke it

#52

Post by iovrthoughtthis » Wed, Mar 28, 2018, 9:46 AM UTC

zer00eyz wrote: post #24

nevatiaritika wrote: post #7

My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…

Im going to say this - When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.

In the quiet isolation of a one2one, perhaps.

Publicly i.e. I front of the team? No. It serves no purpose than to stroke some egos and reduce the "Overton window" of development discussion and experimentation.

Re: It's about what broke, not who broke it

#53

Post by _n_b_ » Wed, Mar 28, 2018, 9:55 AM UTC

I work in the nuclear industry, where most places are pretty good about maintaining a "blame-free" culture. You focus on what processes and procedures failed, what controls were missing, etc., that allowed somebody to make a mistake.

As this attitude was adopted, things shifted too far (at least in the opinion of industry groups, and my observation) to the point where people underperforming to the point of negligence weren't blamed, and the corrective actions to prevent reoccurrences of problems they caused ended up being cumbersome and expensive without really improving safety. (And in this industry, everything relates back to safety.)

In recent years, things have shifted back towards a more pragmatic middle ground. There are tools to assess if a problem was organizational (and it still almost always is) or if there was some element of personal negligence involved. This follows with an industry wide trend of trying to fix the real problems that affect safety and operations, not over-engineer cumbersome corrective actions.

Re: It's about what broke, not who broke it

#54

Post by jerrre » Wed, Mar 28, 2018, 10:15 AM UTC

pnathan wrote: post #26

CoolGuySteve wrote: post #3

I used to think this way until I started working with someone who was nearly always the one who broke it. At some point we just had to face the fact that his work was unreliable even after significant mentoring. If the tasks were difficult that would be one thing, but I'm talking about stuff like committing code to prod that was clearly never even executed once.

Most mistakes aren't problematic. But while we blame the code, not the writer - it serves well to quietly have a counter of "problematic errors" and to keep an eye on the people who increment it the most. After a while, and after a pattern has been established...

You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

Re: It's about what broke, not who broke it

#55

Post by pbhjpbhj » Wed, Mar 28, 2018, 10:17 AM UTC

BrissyCoder wrote: post #4

I don't know. Where I work no discernible pattern can be found with the "what" that broke. It's always the same f *ing people that break it though!

It amuses me that the sibling comments appear unable to imagine the possibility that someone is incompetent.

Of course there are other possibilities - the people breaking things are doing the hard bits that no one else dare to.

Re: It's about what broke, not who broke it

#56

Post by red_admiral » Wed, Mar 28, 2018, 10:18 AM UTC

I'm 90% in agreement. Her workplace definitely sounds like somewhere I'd consider working myself (if I were looking for a job).

There are some things that I consider basic competence standards, like not storing passwords in plain text in any system you're building. I wouldn't fire an intern for getting that wrong but I also wouldn't let an intern near a production authentication system without some oversight.

If someone is a security engineer with a responsibility to know these kinds of things as part of their job role and certification, then if they'd implemented passwords-in-clear to cut corners somewhere, even if it's to meet a really important deadline, I'd be extremely unhappy. Of course I'd establish the general pattern of what had gone wrong first, and if it was a superior being abusive to the security engineer to get the product launched on time I'd still be really unhappy but not at the engineer.

Occasionally one does follow the chain of causes back though and finds not the organisation's culture but an individual who really should have known better.

Re: It's about what broke, not who broke it

#57

Post by dozzie » Wed, Mar 28, 2018, 10:27 AM UTC

csours wrote: post #20

I took down an assembly plant by clicking on a Network status icon from a particular hardware supplier. Over the weekend, firmware patches were applied, and the server rebooted. After reboot, everything worked fine, so the tech marked the change successful and went home. Well, apparently the NICs would work just fine, but not all settings were applied until you opened the UI provided by the vendor. When you opened th…

> [...] not all settings were applied until you opened the UI provided by the vendor. [...] the NICs would reboot, just long enough to kill TCP connections.

The UI part suggests that it was Windows, and if it was, it's not quite the case that "just long enough" to kill TCP connections, as you need quite a lot of downtime to terminate a typical TCP session.

In Windows, if a NIC goes down, all the TCP connections that use the NIC get closed immediately. (Or at least this was the case a few years ago. I had a similar system with similar drawbacks deployed back then, though it was an automated warehouse, not an assembly plant.)

> So who would you even blame there?

The idiots who designed the system to run on non-industrial-grade operating system. Windows was never a good choice to control industrial installations.

Re: It's about what broke, not who broke it

#58

Post by [deleted] » Wed, Mar 28, 2018, 10:38 AM UTC

jerrre wrote: post #54

pnathan wrote: post #26

Earlier quoted context omitted.

Most mistakes aren't problematic. But while we blame the code, not the writer - it serves well to quietly have a counter of "problematic errors" and to keep an eye on the people who increment it the most. After a while, and after a pattern has been established...

You could also have a counter of problematic area's: some parts are easier to break than others, and could be improved/made more robust...

[deleted]

Re: It's about what broke, not who broke it

#59

Post by magic_beans » Wed, Mar 28, 2018, 11:27 AM UTC

nevatiaritika wrote: post #7

My manager at work especially has the reverse attitude where the person who broke it is more significant than what broke/how we fixed it/ how to avoid it in the future. I have seen people get taunted for a bug they caused two years ago, a bug which didn't affect any revenue or was pretty easy to fix. And of course it still gets pointed out during appraisals. Its a nightmare, because there's no room for experiment lef…

Unless you’re on a visa, I don’t understand why anyone would tolerate this. Why not leave this company?

Re: It's about what broke, not who broke it

#60

Post by silveroriole » Wed, Mar 28, 2018, 11:29 AM UTC

iovrthoughtthis wrote: post #52

zer00eyz wrote: post #24

Earlier quoted context omitted.

Im going to say this - When it is all said and done, if you fucked up, you should get some shit for it. However this should be good natured, YOU should be laughing at it and everyone else laughing WITH you.

In the quiet isolation of a one2one, perhaps. Publicly i.e. I front of the team? No. It serves no purpose than to stroke some egos and reduce the "Overton window" of development discussion and experimentation.

To me the one2one situation would feel like I’m surreptitiously getting bollocked for making the mistake, under the guise of humor. In public, on the other hand, I don’t care if someone takes the piss out of my code - I’ll laugh right along with them as long as it’s not overly malicious. IMO it sets a good example not to be precious about your code.