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

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

#31

Post by itronitron » Wed, Mar 28, 2018, 5:18 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…

one view that a lot of your colleagues may have had is that you just made clear to the company how relevant their jobs are (I am assuming most of the systems were built in house) and that decisions that were made in the interest of expediency can now be revisited in order to scope out additional work

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

#32

Post by leoc » Wed, Mar 28, 2018, 5:24 AM UTC

bigiain wrote: post #28

smallbigfish wrote: post #11

Earlier quoted context omitted.

We don't touch production. We don't upgrade. We are are a X million company we can't afford the risks. These are some of the excuses they put up. And then they sit 10 years or more with that bad stuff in there, build even uglier ways around it. But the time comes to actually do something about. And what was once a one day job becomes "we will hire a consultancy firm to guide us".

Ha. "Outsourcing of blame"! Outsourcing of blame - as a Service. Where's my VC???

Accenture. You've invented Accenture.

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

#33

Post by itronitron » Wed, Mar 28, 2018, 5:24 AM UTC

lkrubner wrote: post #30

There is the risk of conflating two separate types of problem. There are problems that arise from the complexity of the code, and problems that arise from particular people. If a programmer has a habit of sloppy code, or violates the team's standards in some ways, then a good leader will keep track of the fact that one person is responsible for a recurring pattern of mistakes. I absolutely agree with Rachel By The Ba…

if the function was still there, I think it is also likely that the old jar or class file (with the function) was still lurking in the classpath or your version control and build system weren't using his revision

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

#34

Post by itronitron » Wed, Mar 28, 2018, 5:28 AM UTC

smallbigfish wrote: post #11

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…

We don't touch production. We don't upgrade. We are are a X million company we can't afford the risks. These are some of the excuses they put up. And then they sit 10 years or more with that bad stuff in there, build even uglier ways around it. But the time comes to actually do something about. And what was once a one day job becomes "we will hire a consultancy firm to guide us".

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

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

#35

Post by bigiain » Wed, Mar 28, 2018, 5:37 AM UTC

leoc wrote: post #32

bigiain wrote: post #28

Earlier quoted context omitted.

Ha. "Outsourcing of blame"! Outsourcing of blame - as a Service. Where's my VC???

Accenture. You've invented Accenture.

Damn.

(Second thought - did they patent it? "A system and method for reallocating blame and responsibility for business related negative outcomes. The negative outcomes include a plurality of career limiting moves and hastily made decisions." ... )

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

#36

Post by realusername » Wed, Mar 28, 2018, 5:47 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's always the same f*ing people that break it though!

Sometimes that's just the people who change things the most and work the hardest. It's harder to break anything when you don't actually change anything.

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

#37

Post by csours » Wed, Mar 28, 2018, 5:58 AM UTC

itronitron wrote: post #31

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…

one view that a lot of your colleagues may have had is that you just made clear to the company how relevant their jobs are (I am assuming most of the systems were built in house) and that decisions that were made in the interest of expediency can now be revisited in order to scope out additional work

Shhhh... stop telling secrets.

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

#38

Post by thinkloop » Wed, Mar 28, 2018, 6:08 AM UTC

itronitron wrote: post #34

smallbigfish wrote: post #11

Earlier quoted context omitted.

We don't touch production. We don't upgrade. We are are a X million company we can't afford the risks. These are some of the excuses they put up. And then they sit 10 years or more with that bad stuff in there, build even uglier ways around it. But the time comes to actually do something about. And what was once a one day job becomes "we will hire a consultancy firm to guide us".

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.

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

#39

Post by nstj » Wed, Mar 28, 2018, 6:14 AM UTC

rachelbythebay wrote: post #23

krallja wrote: post #16

Earlier quoted context omitted.

Rachel is an excellent writer who was on a long break from writing. Seems like HN is happy to read her posts again.

Thanks! I was working a "real job" from about mid 2013 and am no longer, so my cycles are now all mine again. I was too tired to write most of the time before. Also, there are many more stories to be told now!

Nice work! And appreciate the "SuperOP" response :) Keep up the good posts, they're great to read!

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

#40

Post by silveroriole » Wed, Mar 28, 2018, 6:40 AM UTC

Sure, if you have a huge company and a revolving door, the solution is a bunch of processes and idiot-proof safety nets, and no one person is to blame for most bugs. If you’re in a small company, the solution is to teach the devs by showing them what mistakes they made. I don’t think that’s a bad thing; if you write code, that code is your responsibility, and you shouldn’t be sensitive about people telling you your code is broken.

Also, focusing on the code itself, for me at least, easily leads to thoughts like “this function is crap! What idiot wrote this!?”. Finding out who broke it leads to thoughts like “I see John introduced this buggy function. I should go check with him, maybe he had a good reason.”