4 ms·

My not-so-humble opinion is that this type of incremental encoding of process as scripts results in a system built around process rather than a system that eats

My not-so-humble opinion is that this type of incremental encoding of process as scripts results in a system built around process rather than a system that eats process. I'm all for a catalog of scripts automating common tasks. The moment those scripts start getting called by production services you're creating a huge mountain of tech debt for whoever is unfortunate enough to unpick the web of spaghetti. 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. So incremental scale is achieved by stuffing more into the process, which then gets grafted onto the script monolith in a self protruding cycle.

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.)
wavemode 2y ago
How would a do-nothing script be called by production? The whole point is that they're manual. You're basically arguing against the concept of SOPs. OP blog post is basically just a programmer's version of an SOP. SOPs are great, until they aren't. So then you change them. This is nothing new or strange.
j45 2y ago
Bash scripts have a lot less of these issues than scripting built in a build orchestration system. They are more portable, more universal, fewer dependencies. Whenever you start to install something just put the commands into a bash’s script as you go and run it at each step. Want to break it apart? Break apart the script how you like and repeat. Being able to hand someone a scene for Linux or MacOS is a great way to help others begin too.

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.)

wavemode 2y ago

How would a do-nothing script be called by production? The whole point is that they're manual. You're basically arguing against the concept of SOPs. OP blog post is basically just a programmer's version of an SOP. SOPs are great, until they aren't. So then you change them. This is nothing new or strange.

j45 2y ago

Bash scripts have a lot less of these issues than scripting built in a build orchestration system. They are more portable, more universal, fewer dependencies. Whenever you start to install something just put the commands into a bash’s script as you go and run it at each step. Want to break it apart? Break apart the script how you like and repeat. Being able to hand someone a scene for Linux or MacOS is a great way to help others begin too.