At Netflix, our philosophy was to try and remove process at every turn. If something bad happened, we'd look at if there was a process in place, and if so where we could automate or remove that process for better outcomes.
When change requests were not accurate, we removed change requests by automating auditing of the infrastructure, so people could see exactly what state it was actually in, instead of relying on change requests.
When the process for paging someone broke down, we built automation for paging people.
There were many other examples. But always we would look for ways to eliminate process, and for ways to automate around failures instead of introducing new processes.
I've spent my time at smaller less advanced orgs. The pushback against automation, against software has been pretty high.
Skepticism of software is high; people seem to only trust things they can type into the terminal & crank out themselves. They see automated systems as too fancy, too dangerous, as unknowable. Companies and people don't take the time or opportunity to learn, understand and grow: they are committed only to the work ahead of them rather than a broader project of improving themselves & the org broadly.
It's all so backwards & sad. Seeing such persistent anti-commitment to getting good. Regularly taking the most reductionist take on what simple is, even though it so often involves complex tribal/oral knowledge with many unstated embedded choices baked in in how the org handles things.
It's a hard sell, because the base fact is that there is kind of a low cowardice pushing against creating code. Nothing is as well defined, well shareable, as explicit as code. The opportunity to learn from code is as infinite as you are willing to chase it. But people don't want to have to engage in systems or computers. They prefer informal knowledge & having regurgitated oral knowledge passed down, they dont have the fire to investigate & watch for themselves.
I hope we can keep finding ways to make automated systems better explain themselves, better show their work. Automation is just so amazing, but dealing with the fear insecurity & "I have no time for this" factor has been a miserable ever-lowering factor at most orgs I've seen. I wish geeks & orgs could believe more in trying, weren't so predisposed against figuring out good ways to pave the cowpaths.
To play devil's advocate, I frequently see people throw software and automation at problems that could've been solved with a system/design change. "We make 20 of these widgets a day, they take too long to make, let's automate it!" Unfortunately the first questions aren't always "why do we make these widgets?" or "do we have to?"
Lots of out of touch leadership types automate away system design flaws IME. Rather than automating for speed or consistency.
Sure, no code is great when it works. Usually though I think there is a real calling for forward motion, for getting better, not unwinding & disassembling.
Reagrdless of whether we agree here, the question stands of what we do when action is required.
You just go from a process where someone has to remember something to a process where a computer checks a condition thousands of times a day or whatever.
Sure, but that's my point, it boils down to good processes being better than bad processes.
I guess part of what is being talked about here is that people sometimes have trouble reasoning about automation vs reasoning about some human mediated activity.
> My early mindset revolved around trying to fight processes and replace them with some kind of technical solution or automation. I now try to favor communication and investigation to reveal the underlying problem that the process was trying to solve. And sometimes, a broken process may still be better than a broken program. Because human communication is a complex issue that cannot always be fully encapsulated in a rational specification.
This is key. As the old quote goes “Automating a mess means you get an automated mess”. I’ve seen too many managers use process, and too many developers use code, to avoid digging into a mess. A mess involves ugly human emotions and motivations; understanding why the mess is there is scary work. Ignoring that work and focusing on the "technical" leads to weird requirements that then leads to bad software.
It's a real pain to maintain a prematurely automated solution to a social problem. It makes the mess worse.
In my experience most procedures are created not due to a deep nuance to the problem space that makes procedures superior to automation, but rather one of the following:
1. Leadership lacking the technical background to understand what automation would look like or accomplish. (In extreme cases, this can manifest as people creating processes that are redundant with automation capabilities built into the tools they are already using.)
2. Leadership lacking confidence that the organization has the skills or resources to automate effectively.
> Bloaf, it's the employee's job to bring the case for automation to their leadership...
3. People in senior technical roles shooting down automation efforts because a significant amount of their expertise is "expertise in navigating existing processes" and they don't want this expertise to be undermined.
it should be. I keep thinking it about starting a company that builds tooling to fuse all that state together...and then I remember what its like to try to get product traction with developers
Process has to do with people. Hire mature and proactive people, you don't need process but context. As company grows, both culture and talent gets diluted and managers get increasingly removed from reality while more mediocre managers get increasingly more worried about covering their asses. Naturally, processes ensue.
A well-designed technical solution removes the possibility of human error during execution. Given that computers are better at following instructions than humans, I don't see why you wouldn't try to automate as much as possible so that humans have a smaller set of processes to follow and keep track of.
Because often no one remembers what the initial process was supposed to do in the first place, and if the original objective was a bad one, automating it makes it far worse. Example: a publication system vendor left a QA procedure that said "put a space character in the front of all these attribute values when they start with alpha". So the team methodically and wrist-slashingly hand-coded thousands of XML files so that they all had leading whitespace in their attributes. When I came on board, I didn't automate that process out of the gate, because leading whitespace in attributes is f@#ng dumb. If I did, I would have caused a lot more problems downstream - so this was a simple process that needed to really die, or at least get explained. Which, turns out, it did have an explanation: the vendor didn't understand how the FOSI print formatter worked, but they had this workaround that seemed to work, so they handed it down. The real problem was being caused by a mishandling of the entire element in the data structure, which was a much bigger deal.
When change requests were not accurate, we removed change requests by automating auditing of the infrastructure, so people could see exactly what state it was actually in, instead of relying on change requests.
When the process for paging someone broke down, we built automation for paging people.
There were many other examples. But always we would look for ways to eliminate process, and for ways to automate around failures instead of introducing new processes.