Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fake it until you automate it

understandlegacycode.com

Post reply on HN
Print view View original

31–40 of 52 posts

Re: Fake it until you automate it

#31

Post by __MatrixMan__ »

lamontcg wrote: post #30
__MatrixMan__ wrote: post #28

I was doing this a year ago. Now I'm redoing it. In my case, what I missed is that if the app is complex enough you should treat the deployer like a separate product. Different teams might want to use it for different things, deploy different versions with it, etc. So it should be in a separate repo with its own tests and its own version string. Otherwise iterating on it is hell because you're doing so in a space tha…

That is just the next iteration on the "fake it until you automate it" path. And it can actually be a mistake to try to jump from zero directly to fully automated nirvana.

Agreed. I tried to jump too early. More faking it for longer would've been faster in the long run.

Re: Fake it until you automate it

#32

Post by mason55 »

frederikvs wrote: post #27
mason55 wrote: post #13

Earlier quoted context omitted.

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…

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…

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.

Re: Fake it until you automate it

#34

Post by hinkley »

Joel_Mckay wrote: post #2

Try including the IT support cost of the collateral damage unskilled workers can do with administrative rolls. You will end up supporting hundreds if not thousands of operational features. I am not suggesting you should give a toss, but at least admit what happens before you inflict the decision on your team. Have a wonderful day =)

Backpressure is required in order for a distributed system to continue to run successfully. Half the time the people who think they need a new feature just want to be unique.

The critical observation is that these people won't always be around or have this deployment plan fresh in their minds. You need most of your deployments to follow the same kinds of rules, so that when you look at a misbehaving service that you haven't had to deal with in ages, you can figure out what's going on and why it's wedged. Every new thing it can do is tribal knowledge that's not captured anywhere. It might have already walked out the door in fact.

Re: Fake it until you automate it

#35

Post by hinkley »

kevmo314 wrote: post #3

Wow, please don't ship that. A whole suite of CLI tools for a custom deployment pipeline is my worst nightmare if something goes wrong. The purported benefits: > It gets people into the habit of running a single command to initiate deployments npx firebase-tools deploy --only functions -P staging is also one command > It’s a more obvious source of truth for putting the deployment instructions If that command were put…

Not even half, but a pretty decent chunk of my tools are things that someone thought should only happen in CI/CD and then it breaks and there's no way to debug. People are not fond of using your tools when they create blocking issues that are potentially open ended.

Most of your tools should run in CI/CD. That's the goal, and a pretty high priority one. But they can't only be run there.

Re: Fake it until you automate it

#36

Post by polyrand »

The thing about automation is that it is really hard to automate workflows completely while getting everything right. One approach I like is the "Pareto automation"[0]. Normally, you can automate the most fragile or tedious parts of a workflow with little effort and keep doing everything else manually. Also, sometimes you don't even need automation, you just need a checklist.

[0]: https://ricardoanderegg.com/posts/musings-thoughts-software-...

Re: Fake it until you automate it

#37

Post by drewcoo »

__MatrixMan__ wrote: post #28

I was doing this a year ago. Now I'm redoing it. In my case, what I missed is that if the app is complex enough you should treat the deployer like a separate product. Different teams might want to use it for different things, deploy different versions with it, etc. So it should be in a separate repo with its own tests and its own version string. Otherwise iterating on it is hell because you're doing so in a space tha…

> So it should be in a separate repo

If it's in the same repo, that means all of the features of the deployer can match the deployed code automatically - the deployer is made for and tested for that version.

With different repos, you add complexity. Now you have to support deploying multiple versions so there are more code paths and there's version checking etc. And more complexity also means you need more tests.

Re: Fake it until you automate it

#38

Post by latexr »

polyrand wrote: post #36

The thing about automation is that it is really hard to automate workflows completely while getting everything right. One approach I like is the "Pareto automation"[0]. Normally, you can automate the most fragile or tedious parts of a workflow with little effort and keep doing everything else manually. Also, sometimes you don't even need automation, you just need a checklist. [0]: https://ricardoanderegg.com/posts/mu…

> Normally, you can automate the most fragile or tedious parts of a workflow with little effort and keep doing everything else manually. Also, sometimes you don't even need automation, you just need a checklist.

That’s what the post’s approach gives you: a checklist you run in order, with some steps automated.

Re: Fake it until you automate it

#39

Post by urthor »

polyrand wrote: post #36

The thing about automation is that it is really hard to automate workflows completely while getting everything right. One approach I like is the "Pareto automation"[0]. Normally, you can automate the most fragile or tedious parts of a workflow with little effort and keep doing everything else manually. Also, sometimes you don't even need automation, you just need a checklist. [0]: https://ricardoanderegg.com/posts/mu…

My favorite trick is simple.

I don't "fully" automate. I partially automate, then build my workflows from these composite parts. Composition.

For a start, I file all my bash scripts/notes/snippets in Vimwiki. Zettelkasten is truly brilliant.

Then... I write almost everything I do INTO Vimwiki (git is for programs, Vimwiki is for snipppets. Vimwiki is managed with Chezmoi). Hence, whenever I need to do... anything... I can build that workflow out of past snippets from the Vimwiki filing system.

Over time, my workplace and home workflows are automated. You know it's automated once you find a "set" composition, you use for 2 weeks straight without variation.

I only bundle "set" workflows, which haven't changed, into discrete scripts.

Re: Fake it until you automate it

#40

Post by mikeyouse »

Joel_Mckay wrote: post #2

Try including the IT support cost of the collateral damage unskilled workers can do with administrative rolls. You will end up supporting hundreds if not thousands of operational features. I am not suggesting you should give a toss, but at least admit what happens before you inflict the decision on your team. Have a wonderful day =)

God, this is good advice. Living this hell at the moment. Just a complete "throw every feature at the wall" environment where nothing is documented and it's an infinitely expanding Kessler Syndrome-like failure of "automation".
Post reply on HN