Hacker News Reader

Comment by kqr | Hacker News Reader

The last point is one I've been employing very successfully lately. I think Toyota speaks of it as "figure out a really good process using humans first, then consider automating."

Doing something manually takes less time than you think if you create a good standard sequence that irons out most of the mechanical waste involved. Once the process starts to provide a lot of value (or no value – which is most commonly the case!) you can decide to automate further (or not at all.)

But also at that point you have to be careful. Automate little steps at a time. Automate the easy, happy path first and quickly bail out to the human operator if something goes wrong, then reconsider if the economics are still in favour of further automation. The last percent of automation are invariably the most expensive, by far.

View on HN

Yes, I recently planned out how to transition a company to a continuous delivery release model, and this was part of the plan.

One thing I insisted on was on building and running playbooks, rather than jumping to full automation from merge to production. This phase was temporary: it might only take a few weeks or months before people will get bored with this and find it tedious. When _boredom_ is the biggest problem you have with a process, then it's time to automate.

But in the meantime, going through these motions manually has educational value, and lets you refine your processes easily.

Automating a process tends to ossify it, and concentrate knowledge about it in whoever creates and maintains the automation. Playbooks distribute knowledge to whoever executes them, and make systems amenable to change.

I read that the Airbnb founders tried to instill an ethos in the early days of "do everything by hand until it's painful," because they were scaling so fast and they wanted to avoid nailing down a process too early.

Completely agreed on all points. It can be all too easy to say, we need to build a widget factory so we can automatically create 100 widgets for our customers. It'll be so efficient! But once you start building the factory, you realize that you'd probably have reached your goal faster by making them manually and only coming back later to find out what was common between them. Start small.

In my experience, this is also good advice when thinking about distributed systems. If an algorithm doesn't make sense when imagined with people in an office, it usually also doesn't work in a computer.

Automation is such a useless word. It can mean "no human in the loop" but is can also mean "human pushes this button and machine works" and also "all I have to do is frobnicate the urbanizer, input the result, doublecheck the nitifier, push the button, and then the machine does the rest!".

The Toyota quote is clearly skewed towards industrial production, where the word is a little more useful though. But other times, a simple process without human involvement might very well be the cheapest and easiest to start with too.

Granted, this was also in the context of mechanical engineering and manufacturing (cf. remarks in sibling comment), but Elon Musk has talked about his engineering philosophy in five steps in a starbase tour/interview video:

1. Make the requirements less dumb 2. Try deleting the part or process 3. Simplify and optimize the design 4. Accelerate cycle time 5. Only then: Automate

I think this touches upon the same issues, namely that you shouldn't automate something if you don't have to, and even less if you don't need it in the first place.

I also recently read Elon strongly criticizing/advising another company to 'get their factory [processes] working before building the big factory', which is the exact opposite of what said company was doing...

Seems like Elon is correctly advising those guys to avoid a lot of pain (while not-so-subtly pointing out to everyone the big mistake being made).

When being hired to automate a business process, I always tried to get/work with the client to explicitly streamline the paper/people version of the process first, and when they did a good job of it, the automation went well. I'd tell them that automating a mess just made a turbocharged mess, and merely guessing at what changes (implemented in automation) would be better was a crapshoot. If anything, I'd recommend making that approach a stronger requirement for taking on jobs.

Reply on news.ycombinator.com