[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)