Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Whilst I agree with the article being that context matters a lot. But there are a lot of great things about RCAs.

A few of the things:

1. It shows visibility about the engineer's abilities

2. It attempts to show weaknesses of technology choices that happen above the people who support it

3. It attempts to show a weakness in the process. (Similar to a retro) Yet, in practice, rarely is this addressed.



Stopping before reaching the process is a big mistake many do when doing RCA. For example: Why did program crash: [Divide by zero]. Why? [Loop iterating array not terminated] Why? [Input arguments not validated] Why? [Developer was "sloppy"] and then they stop there.

The answer to the last question should instead be on or many of: no unit tests, no code reviews, working overtime, no QA before shipping, can't concentrate in open landscape, compiler warnings disabled, using too low-level programming language for high level logic, developers not educated on current tech stack, and so on. With follow up whys on all of those.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: