4 ms·

This seems like the same basic concept as https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ https://blog.danslimmon.com

This seems like the same basic concept as https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...

mason55 4y ago
I remember when that article first made the rounds. I had been doing something like that for a few years already and the article did a good job making all the same points I would have made. In hindsight, the biggest challenge that I've found is getting your "do-nothing script" to become the authoritative source of how to do something. The fact that the steps themselves are still manual means that it's easy for people to create their own manual side paths to cover new situations and it's hard to get those added back into the script. If your CI/CD server is running all the steps then the only way to make something happen is to get it into the build script. If there are humans in the loop then there will always be new things that come up, people who do them in slightly different ways, and stuff that doesn't get committed back into the scripts.
- frederikvs 4y ago
  My interpretation was always that the do-nothing script was just a starting point - once you have it, you can gradually start automating the steps. Once the script actually automates a few of the more tedious steps, people are much more likely to use it. And when they use it, they're likely to help maintain it when new situations need it. Eventually, you may end up with a script that does automate it all, and can be put in CI/CD. (Hey, I can dream, can't I?)
  - mason55 4y ago
    Yes, I agree 100%. But until you get to the point where it's fully automated and running through CI/CD then you're constantly fighting new manual steps and ways to do things. > And when they use it, they're likely to help maintain it when new situations need it. Unfortunately, "likely" means "not always", which turns into something that is no longer a real source of truth, and you're back to people having their own undocumented way of doing things. I've also found that it's easier to bikeshed when you're printing our commands for people to run. Either because they see the command more clearly or they have different dependencies installed. It's still better than nothing, don't get me wrong. It's just become clear to me that if you don't build your "do-nothing script" with a real plan to get it automated (i.e. not just a dream that "we'll automate this one day") then it will quickly rot.
mr-karan 4y ago
The author of this blog also has published a library for people looking for a more advanced version of that script: https://github.com/danslimmon/donothing https://github.com/danslimmon/donothing
armSixtyFour 4y ago
In general I find this concept pretty helpful. I've found it really helpful to make functions in my bash profile that have TODO statements for things that I have yet to completely automate, but still want an easy way to look up. My only issue is that not automating the deploy is probably the worst thing to need to do manually. Having worked at a company that had a rather large and ever changing list of steps to complete in order to deploy (which took a 1-2 hours), it's something I find myself prioritizing now.
trailynx 4y ago
Prior discussion of that link: https://news.ycombinator.com/item?id=29083367 https://news.ycombinator.com/item?id=29083367 I personally like the name „checklist script“ (also checkscript) for that, which I found in that comments at the time. I think it conveys easily the two purposes of the thing (checklist gradually becoming a script).

This seems like the same basic concept as https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/ https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-...

mason55 4y ago

I remember when that article first made the rounds. I had been doing something like that for a few years already and the article did a good job making all the same points I would have made. In hindsight, the biggest challenge that I've found is getting your "do-nothing script" to become the authoritative source of how to do something. The fact that the steps themselves are still manual means that it's easy for people to create their own manual side paths to cover new situations and it's hard to get those added back into the script. If your CI/CD server is running all the steps then the only way to make something happen is to get it into the build script. If there are humans in the loop then there will always be new things that come up, people who do them in slightly different ways, and stuff that doesn't get committed back into the scripts.

frederikvs 4y ago
My interpretation was always that the do-nothing script was just a starting point - once you have it, you can gradually start automating the steps. Once the script actually automates a few of the more tedious steps, people are much more likely to use it. And when they use it, they're likely to help maintain it when new situations need it. Eventually, you may end up with a script that does automate it all, and can be put in CI/CD. (Hey, I can dream, can't I?)
- mason55 4y ago
  Yes, I agree 100%. But until you get to the point where it's fully automated and running through CI/CD then you're constantly fighting new manual steps and ways to do things. > And when they use it, they're likely to help maintain it when new situations need it. Unfortunately, "likely" means "not always", which turns into something that is no longer a real source of truth, and you're back to people having their own undocumented way of doing things. I've also found that it's easier to bikeshed when you're printing our commands for people to run. Either because they see the command more clearly or they have different dependencies installed. It's still better than nothing, don't get me wrong. It's just become clear to me that if you don't build your "do-nothing script" with a real plan to get it automated (i.e. not just a dream that "we'll automate this one day") then it will quickly rot.

mr-karan 4y ago

The author of this blog also has published a library for people looking for a more advanced version of that script: https://github.com/danslimmon/donothing https://github.com/danslimmon/donothing

armSixtyFour 4y ago

In general I find this concept pretty helpful. I've found it really helpful to make functions in my bash profile that have TODO statements for things that I have yet to completely automate, but still want an easy way to look up. My only issue is that not automating the deploy is probably the worst thing to need to do manually. Having worked at a company that had a rather large and ever changing list of steps to complete in order to deploy (which took a 1-2 hours), it's something I find myself prioritizing now.

trailynx 4y ago

Prior discussion of that link: https://news.ycombinator.com/item?id=29083367 https://news.ycombinator.com/item?id=29083367 I personally like the name „checklist script“ (also checkscript) for that, which I found in that comments at the time. I think it conveys easily the two purposes of the thing (checklist gradually becoming a script).