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

41–50 of 52 posts

Re: Fake it until you automate it

#41

Post by wruza »

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…

Checklists may sound dumb and boring, but they are actually great! They make it easy to just do the job and not think much about its structure, somehow reducing overall tediousness. Checklists together with snippets in some sort of a knowledge base (I simply use OBTF.txt with folds) help with processes that are too hard to automate timely and/or completely. This also enables gradual automation and knowledge collection rather than living in all-or-nothing world. Also, I find it very useful when your knowledge base grows without being shaped for and nailed down to a specific project with its own quirks. It becomes your own well-commented stdlib for doing things.

Re: Fake it until you automate it

#42

Post by bobkazamakis »

drewcoo wrote: post #37
__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.

if it's not in the same repo, it means that the deployer can be updated and rolled out independently, and scale with its own resources.

if it's in the same repo, you add complexity -- now I have to ensure my deployment of two unrelated code bases don't collide, there's more cross-team conflicts, and I have to clone down a 200gb repo.

Re: Fake it until you automate it

#44

Post by twawaaay »

One thing I noticed is that knowing how things can be automated causes teams to actually get slower at getting stuff done.

First, because automation takes some upfront effort to get done.

Second, because once it is set up it frequently acts to prevent change.

I find it is useful to consider alternative solutions to the problem like a checklist (which I call a program that runs on people) which allows you to set up a process in minutes (+ potentially a meeting with your team) and then get back to the project. Once the project has been running for some time you will be in a better position to automate it. First, you will already have some experience with running the process (with the checklist). And second you can plan the task of automating at lower priority and without it becoming a blocker in your more important project.

Yes, it is considered technical debt. Not all debt is bad.

Re: Fake it until you automate it

#45

Post by [deleted] »

twawaaay wrote: post #44

One thing I noticed is that knowing how things can be automated causes teams to actually get slower at getting stuff done. First, because automation takes some upfront effort to get done. Second, because once it is set up it frequently acts to prevent change. I find it is useful to consider alternative solutions to the problem like a checklist (which I call a program that runs on people) which allows you to set up a…

[deleted]

Re: Fake it until you automate it

#47

Post by armSixtyFour »

abathur wrote: post #7

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

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.

Re: Fake it until you automate it

#48

Post by trailynx »

abathur wrote: post #7

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

Prior discussion of that link: 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).

Re: Fake it until you automate it

#49

Post by perlgeek »

xyzzy4747 wrote: post #22

Please don't do this on a $0 MRR project. Wait until it's a viable company before spending time automating everything.

If you're very early, you want to automate enough to be able to iterate quickly.

That's not the same as automating "everything", of course.

Re: Fake it until you automate it

#50

Post by __MatrixMan__ »

bobkazamakis wrote: post #42
drewcoo wrote: post #37

Earlier quoted context omitted.

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

if it's not in the same repo, it means that the deployer can be updated and rolled out independently, and scale with its own resources. if it's in the same repo, you add complexity -- now I have to ensure my deployment of two unrelated code bases don't collide, there's more cross-team conflicts, and I have to clone down a 200gb repo.

Right, and not just one 200gb repo. If I want to do a git bisect of the app while holding the deployer constant I have to wrangle at least two of them.
Post reply on HN