4 ms·
I read that sentence as "Failures should be documented. If something failed in the past and the underlying issue why it failed is still there, it's useless to a
by 908B64B197 6y ago
I read that sentence as "Failures should be documented. If something failed in the past and the underlying issue why it failed is still there, it's useless to attempt it".
Ex: Using language Y for X was a disaster because of Y didn't have hardware acceleration and we were unable to reach goal Z. Before attempting to use language Y in production again, make sure platform support has improved.
- WJW 6y agoI wonder how many confounding factors there are though. At one point when I had just joined a companyy, a colleague in the process of leaving told me very confidently "at our scale it is not possible to do X anymore". Obviously, we got X working the very next week. What if using language Y for X was a disaster because of poor programming skills or micromanagers? In my experience it is very rarely as clear cut as "Y does not have hardware acceleration support" and there is not really enough rigour in the software engineering process to really figure out where a failure came from.
- 908B64B197 6y agoI also agree with that. I think it's more about infusing an engineering mindset where there is an analysis of past failures.