[HN Gopher] Technical Solutions versus Processes ___________________________________________________________________ Technical Solutions versus Processes Author : greatNespresso Score : 18 points Date : 2023-04-04 08:09 UTC (14 hours ago) (HTM) web link (lucaskostka.com) (TXT) w3m dump (lucaskostka.com) | k__ wrote: | _" code ... is surrounded by context and history that you can | usually browse at will"_ | | Don't know what code that dude encountered, but that hasn't been | my experience. | aleksiy123 wrote: | This could really benefit from a max-width that is smaller. | hintymad wrote: | 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. | onion2k wrote: | _I now try to favor communication and investigation to reveal the | underlying problem that the process was trying to solve._ | | That sounds like a really great process. | bloaf wrote: | The fastest, most bug free code is the code that doesn't need to | run. | | The most consistently implemented procedure is the one that | doesn't require anyone to do anything. | | I agree that when looking at a process that seems bloated and | inefficient, we should be mindful of the XY problem: | https://en.wikipedia.org/wiki/XY_problem | | 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. | lukew3 wrote: | 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. | MilStdJunkie wrote: | 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. | jedberg wrote: | 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. ___________________________________________________________________ (page generated 2023-04-04 23:00 UTC)