4 ms·

I'd say that's just the view from one side. If you overdo your automation without considering generalization and parameters, you lose flexiblity. But when appr

I'd say that's just the view from one side. If you overdo your automation without considering generalization and parameters, you lose flexiblity. But when approached from the other side, you can also have generalization without automation: if you don't create a script for your five commands even if they turn out to be used over and over again. For example, I'm imagining deployment of software releases: 1. If you don't even have a defined way of deploying a release, you have neither generalization nor automation 2. If your deployment is well defined, but requires several commands to be executed manually each time, you have generalization, but no automation 3. If you can deploy a release with a single command or two, you have both generalization and automation 4. If your release always deploys on a git push automatically, you lost generalization again The last one is maybe a little odd, but in terms of generalization, I think of it as "being in control of which version is deployed without working against your own scripts".

xorcist 4y ago
The very commands are in themselves a script. Your command history is a script. Take bash, for example. Is "a; b" one command or two? The answer is well defined but also useless. Every command is the automation of millions of instructions anyway. This goes for other types of command interaction as well, not just command lines. Think about what "creating a script" actually entails. That's parameterization, not automation. That may seem like a silly definition game, but it's hinders the understanding of non-IT people to reason about automatic data processing. The example about software releases is a good example which I think illustrates the limited usability of the concept of automation within IT. The difference between deploying software with two commands or five commands, the difference between your scenario two and three, does not represent differences in automation levels. Not as long as the two (or five, or ten) commands are constant and well defined! Those five commands could for all practical purposes be regarded as one. There may well be examples where only one command is needed, but one which is more complex than five commands together! Which one would be the most "automated" scenario then? The difference between your second and third scenario is one of granularity, not automation. The idea being that it is irrelevant how many commands a step consists of, but instead how many steps there are, where each step can be single stepped, paused, and re-run. And that is a difference in granularity, not in automation. I hope to have shown that the idea of automation is damaging to modelling IT processes. The important scenario of your example is actually the first one. Is the release process well defined? If it is, the rest is implementation. And that implementation is generalization, not automation. Someone who does not recognize that is bound to do a lot of useless unnecessary work, which is something observed in practice many times.

xorcist 4y ago

The very commands are in themselves a script. Your command history is a script. Take bash, for example. Is "a; b" one command or two? The answer is well defined but also useless. Every command is the automation of millions of instructions anyway. This goes for other types of command interaction as well, not just command lines. Think about what "creating a script" actually entails. That's parameterization, not automation. That may seem like a silly definition game, but it's hinders the understanding of non-IT people to reason about automatic data processing. The example about software releases is a good example which I think illustrates the limited usability of the concept of automation within IT. The difference between deploying software with two commands or five commands, the difference between your scenario two and three, does not represent differences in automation levels. Not as long as the two (or five, or ten) commands are constant and well defined! Those five commands could for all practical purposes be regarded as one. There may well be examples where only one command is needed, but one which is more complex than five commands together! Which one would be the most "automated" scenario then? The difference between your second and third scenario is one of granularity, not automation. The idea being that it is irrelevant how many commands a step consists of, but instead how many steps there are, where each step can be single stepped, paused, and re-run. And that is a difference in granularity, not in automation. I hope to have shown that the idea of automation is damaging to modelling IT processes. The important scenario of your example is actually the first one. Is the release process well defined? If it is, the rest is implementation. And that implementation is generalization, not automation. Someone who does not recognize that is bound to do a lot of useless unnecessary work, which is something observed in practice many times.