6 ms·

I'm a big fan of this approach. In general it's another way of defining interfaces around processes. Those processes may be manually done or automated. But the

by IanCal 2y ago

I'm a big fan of this approach. In general it's another way of defining interfaces around processes. Those processes may be manually done or automated. But the interface can remain the same - this is quite powerful when it comes to automating steps. It's the same as you'd do with another system really. I've used this before with Google sheets being manually filled in -> automated with a script. And with Jira tickets being raised and then automatically picked up and processed. It lets you get started sooner, automated the most annoying parts and you never have to fully do it. Side benefit of do nothing scripts is that they can remain up to date more often as they can be more likely to be actually used than reading the docs.

itomato 2y ago
Yes and for me this an another chance to use and share Jupyter notebooks. Describe the thing. Offer boilerplate, examples, or parameterized executables. The doc system that uses Notebooks de facto would be awesome. It’s too heavy to add as a layer to a Cloud SaaS like Confluence and offers too many opportunities for escalations as is..
dheera 2y ago
I would prefer if the script did the things that already are a command. It can confirm with the user: "Execute command (y/N)?" Fuck cutting and pasting stuff from one terminal into another terminal. That's also focus-intensive. Then prompt the user to do the manual stuff when it isn't yet a command: "Look up the e-mail address for foo. Paste it here:" "Put that shit in 1Password: Are you done (y/N)?"
- patcon 2y ago
  I think the point is that it's a psychological hack to just get started. It's making a point, and the point is that it's even helpful without running the commands. Yeah, sure you can immediately make it run the command as soon as it exists -- the article is not implying that that's wrong
  - IanCal 2y ago
    You also get to a point that's functional but not optimal very quickly. Improvements can then be added incrementally by different people as and when it's worthwhile.
    - SoftTalker 2y ago
      And often it doesn’t need to be optimal. If the functional process takes 5 minutes and you do it once a month then you can’t spend more than 5 hours optimizing it before you’re going backwards. https://xkcd.com/1205/ https://xkcd.com/1205/
      - patcon 2y ago
        I feel the place where that intuition might have an exception is where you want a culture change, or you want to communicate a culture of "anyone can do this and is encouraged to". Sometimes it makes sense to automate something that doesn't save time, like putting it in a chatbot command that invites others to run it :)
- IanCal 2y ago
  Then automate those points as and when it's worth doing. Nobody is saying you can't do that, in fact it's a very key selling point of a do nothing script - you can very easily upgrade it to a do something script. The alternatives are "do everything scripts" which get lost in dealing with how to automatically manage 1password, or documentation which is just a do nothing script that doesn't lead you through the checklist.
- Xmd5a 2y ago
  >Fuck cutting and pasting stuff from one terminal into another terminal. This is the point of this approach. To offer incentives to turn into scripts maintenance procedures that come around often but for which there isn't enough budget. I think jupyter notebooks are better suited to fill this role since you can gradually turn a 100% markdown wiki document into a script and offer one-click execution.
0xfaded 2y ago
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?
hinkley 2y ago
My previous approach was: 1) Capture the process as is 2) make the process pass a giggle test 3) make the process automatable Concurrent with 3 and 4: - use the process repeatedly and by as many people as possible - adapt the process to any misuse seen in the wild 4) automate the process Everybody will buy into steps 1&2, and most people will come around to 4, but doing step 3 usually will get you more people pushing for and understanding 4 The limitation of your approach I will say is that if you can automate the beginning of a process or the end it’s fine, but if you have two islands in the middle it doesn’t work better than a CLI tool with prompts.
- catlifeonmars 2y ago
  What’s a giggle test?
  - hinkley 2y ago
    One of the fun things with SEI Capability Maturity Model is that you reach level 1 just by having your process written down at all, no matter how stupid it sounds. But the giggle test is just something I borrowed from business, which is, “can I say this with a straight face?” Which eliminates a lot more censorious than you would think. Writing something down is one thing, making eye contact with someone while repeating it is a bit harder.
    - deleted 2y ago
      [deleted]
    - natch 2y ago
      What’s a censorious as a noun? Hadn’t heard it used that way before.
      - knome 2y ago
        censorious appears to mean 'severely critical of others'. I expect they meant 'censoriously', with the full intent being that the embarrassment felt by the critical reactions of others when reading the instructions out loud will cause you to eliminate or fix obviously broken, complex or tedious processes that you had, until then, just quietly been putting up with.
dejj 2y ago
I see the mountain of “Zen and the Art of Motorcycle Maintenance” coming into view. The approach replaces Confluence instruction pages with semi-interactive walkthroughs (the conscious side). The other side is test automation: it starts with a big ball of overfitted Xpaths and undocumented steps. Those get re-discovered every time the application changes (the subconscious side). Hopefully, we reach the summit where we can execute quickly and still know how we got there and why.

by IanCal 2y ago

itomato 2y ago

Yes and for me this an another chance to use and share Jupyter notebooks. Describe the thing. Offer boilerplate, examples, or parameterized executables. The doc system that uses Notebooks de facto would be awesome. It’s too heavy to add as a layer to a Cloud SaaS like Confluence and offers too many opportunities for escalations as is..

dheera 2y ago

I would prefer if the script did the things that already are a command. It can confirm with the user: "Execute command (y/N)?" Fuck cutting and pasting stuff from one terminal into another terminal. That's also focus-intensive. Then prompt the user to do the manual stuff when it isn't yet a command: "Look up the e-mail address for foo. Paste it here:" "Put that shit in 1Password: Are you done (y/N)?"

patcon 2y ago
I think the point is that it's a psychological hack to just get started. It's making a point, and the point is that it's even helpful without running the commands. Yeah, sure you can immediately make it run the command as soon as it exists -- the article is not implying that that's wrong
- IanCal 2y ago
  You also get to a point that's functional but not optimal very quickly. Improvements can then be added incrementally by different people as and when it's worthwhile.
  - SoftTalker 2y ago
    And often it doesn’t need to be optimal. If the functional process takes 5 minutes and you do it once a month then you can’t spend more than 5 hours optimizing it before you’re going backwards. https://xkcd.com/1205/ https://xkcd.com/1205/
    - patcon 2y ago
      I feel the place where that intuition might have an exception is where you want a culture change, or you want to communicate a culture of "anyone can do this and is encouraged to". Sometimes it makes sense to automate something that doesn't save time, like putting it in a chatbot command that invites others to run it :)
IanCal 2y ago
Then automate those points as and when it's worth doing. Nobody is saying you can't do that, in fact it's a very key selling point of a do nothing script - you can very easily upgrade it to a do something script. The alternatives are "do everything scripts" which get lost in dealing with how to automatically manage 1password, or documentation which is just a do nothing script that doesn't lead you through the checklist.
Xmd5a 2y ago
>Fuck cutting and pasting stuff from one terminal into another terminal. This is the point of this approach. To offer incentives to turn into scripts maintenance procedures that come around often but for which there isn't enough budget. I think jupyter notebooks are better suited to fill this role since you can gradually turn a 100% markdown wiki document into a script and offer one-click execution.

0xfaded 2y ago

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?

hinkley 2y ago

My previous approach was: 1) Capture the process as is 2) make the process pass a giggle test 3) make the process automatable Concurrent with 3 and 4: - use the process repeatedly and by as many people as possible - adapt the process to any misuse seen in the wild 4) automate the process Everybody will buy into steps 1&2, and most people will come around to 4, but doing step 3 usually will get you more people pushing for and understanding 4 The limitation of your approach I will say is that if you can automate the beginning of a process or the end it’s fine, but if you have two islands in the middle it doesn’t work better than a CLI tool with prompts.

catlifeonmars 2y ago
What’s a giggle test?
- hinkley 2y ago
  One of the fun things with SEI Capability Maturity Model is that you reach level 1 just by having your process written down at all, no matter how stupid it sounds. But the giggle test is just something I borrowed from business, which is, “can I say this with a straight face?” Which eliminates a lot more censorious than you would think. Writing something down is one thing, making eye contact with someone while repeating it is a bit harder.
  - deleted 2y ago
    [deleted]
  - natch 2y ago
    What’s a censorious as a noun? Hadn’t heard it used that way before.
    - knome 2y ago
      censorious appears to mean 'severely critical of others'. I expect they meant 'censoriously', with the full intent being that the embarrassment felt by the critical reactions of others when reading the instructions out loud will cause you to eliminate or fix obviously broken, complex or tedious processes that you had, until then, just quietly been putting up with.

dejj 2y ago

I see the mountain of “Zen and the Art of Motorcycle Maintenance” coming into view. The approach replaces Confluence instruction pages with semi-interactive walkthroughs (the conscious side). The other side is test automation: it starts with a big ball of overfitted Xpaths and undocumented steps. Those get re-discovered every time the application changes (the subconscious side). Hopefully, we reach the summit where we can execute quickly and still know how we got there and why.