3 ms·
On that day, most probably nothing with regards to this task. Then, later, probably someone would check out the scripts from a shared repo. Then, read an outda
by krab 6y ago
On that day, most probably nothing with regards to this task.
Then, later, probably someone would check out the scripts from a shared repo. Then, read an outdated README, try it out, swear a bit, check for correctness with someone dependent on the results, and finally learn how to do the task.
There is a lot of business processes that can tolerate days or weeks of delay in case of such a tragic (and hopefully improbable) event. The trick is to know which of them can't.
- nicbou 6y agoThat second paragraph is very relatable.
- darkwater 6y ago> There is a lot of business processes that can tolerate days or weeks of delay in case of such a tragic (and hopefully improbable) event. The trick is to know which of them can't. This is really true BUT that kind of problems are OK - nobody cares - until somebody starts caring and then all of a sudden it is urgent (exactly because they were undetected for weeks/months due to their periodicity)
- krab 6y agoI meant it's fine to take calculated risks. E. g. we have less than 1% chance per year that a given person leaves us on bad terms or suffers a bad accident or illness. In case it really happens, it will cost us X in delays and extra work. To lower the probability of this risk to Y% would cost us Z (money, delay, etc). If you do this math, you can tell if it's a good idea to optimize here, or if you have more pressing issues. In my experience, this sort of one-man jobs gets automated or at least well described and checked for fear of mistakes and/or employee fraud rather than "downtime".
- darkwater 6y agoMistakes are "downtime" as well in a way. Or maybe better, downtime is a mistake, cause errors and lead to problems.