2 ms·

I'm confused as to what you're picturing. > The moment those scripts start getting called by production services Any of them with manual steps just can't, rig

by IanCal 2y ago

I'm confused as to what you're picturing. > The moment those scripts start getting called by production services Any of them with manual steps just can't, right? > Further, because your human oriented process has now codified your system, changes to the system that's would be beneficial to a software system (i.e. dividing the system into components) are impossible. Absolutely nothing stops you from changing these scripts - it's no different from having scripts in a package.json The alternatives are full automation, which pushes your issues to the max, or zero automation which is an odd point to be in.

szundi 2y ago
No, the point of the article is that later these can be modified to actually run these commands - obviously to call these scripts. You can assume pretty confidently that when it seems to be a self contained good script, it is going to be called from services. Even if it is a bad investment to implement it, because programmers hate boring tasks. They would even choose to make a web of spaghettis for later generations than do boring stuff.
- IanCal 2y ago
  I absolutely agree you modify and automate parts (and eventually all) of it. It's the leap to having scripts in a repo being called from production services I'm less convinced by. As I said, the alternatives to part/incremental automation is none or total automation and total has the same issue right? Or do you mean by automating one step in a script, you risk someone using that part in a production service?
dragonwriter 2y ago
> Any of them with manual steps just can't, right? If you are literally using the kind of scripts used here, they can't be called by a production system though their use can be part of formalized desk procedures. It is a fairly natural next step (and a not unheard of first step in automation, bypassing these) to instead build something like these scripts but into an actual workflow management system where it can be triggered by either a user or even automatically tied to another system event, can be assigned to an available worker, can have status and artifacts tracked, and can trigger downstream processes. (Of course, once you have the process in such a system, where the human worker is essentially a component the system calls to complete defined steps—contrary to GPs criticism—what you have is equqivalent to a documented process with the notable different that it is much easier to refactor it to divide work among components, etc., just loke any other software system.)

by IanCal 2y ago

szundi 2y ago

No, the point of the article is that later these can be modified to actually run these commands - obviously to call these scripts. You can assume pretty confidently that when it seems to be a self contained good script, it is going to be called from services. Even if it is a bad investment to implement it, because programmers hate boring tasks. They would even choose to make a web of spaghettis for later generations than do boring stuff.

IanCal 2y ago
I absolutely agree you modify and automate parts (and eventually all) of it. It's the leap to having scripts in a repo being called from production services I'm less convinced by. As I said, the alternatives to part/incremental automation is none or total automation and total has the same issue right? Or do you mean by automating one step in a script, you risk someone using that part in a production service?

dragonwriter 2y ago

> Any of them with manual steps just can't, right? If you are literally using the kind of scripts used here, they can't be called by a production system though their use can be part of formalized desk procedures. It is a fairly natural next step (and a not unheard of first step in automation, bypassing these) to instead build something like these scripts but into an actual workflow management system where it can be triggered by either a user or even automatically tied to another system event, can be assigned to an available worker, can have status and artifacts tracked, and can trigger downstream processes. (Of course, once you have the process in such a system, where the human worker is essentially a component the system calls to complete defined steps—contrary to GPs criticism—what you have is equqivalent to a documented process with the notable different that it is much easier to refactor it to divide work among components, etc., just loke any other software system.)