3 ms·
There was a post here a few weeks ago reminding us of the dangers of this approach. I don't have the link but the essence is here: After a process gets automat
by nimrody 6y ago
There was a post here a few weeks ago reminding us of the dangers of this approach. I don't have the link but the essence is here:
After a process gets automated, people forget the details of how to do the work manually. Now, when the automation breaks (and it will break at some point. It takes a huge amount of work to make these things failsafe and scripting doesn't really encourage robustness) -- no one remembers the details and fixing the issue is more difficult and requires specialized knowledge that is no longer common in the organization.
- mxuribe 6y agoTotally agree, and i've seen this many times (and have had my teams "clean up" after others). however, what can help mitigate - maybe not fully prevent - in some cases are the following 2 approaches: 1. Build automation so that it is NOT such a blackbox. I even go so far as to build automation with scripting languages...that allows myself/my team to at least peek at the source code to see what is happening. 2. And, of course documentation. i know this is simplistic of me to state...but it is invaluable nonethelss. I should also clarify that i mean there should exist documentation both for users, or by extension those who benefit from the automation, as well as, for developers/sys admins/sys maintainers (say, within the code itself).
- gglitch 6y agoThis sounds to me like not a failure of automation as such, but of process/knowledge management by the team that builds the automation. No process is permanently exempt from entropy.