[HN Gopher] Beware of the Turing tar-pit (2004)
       ___________________________________________________________________
        
       Beware of the Turing tar-pit (2004)
        
       Author : sph
       Score  : 36 points
       Date   : 2024-05-03 05:25 UTC (2 days ago)
        
 (HTM) web link (weblog.raganwald.com)
 (TXT) w3m dump (weblog.raganwald.com)
        
       | joe_guy wrote:
       | > Keep Alan Kay's words in mind: "We aim to make simple things
       | simple and complex things possible." When solving the general
       | problem makes complex things possible, that's good. But it
       | shouldn't be at the expense of making simple things simple.
       | 
       | Great quote.
        
       | robertclaus wrote:
       | I think this is really good advice. I've always tried to teach
       | this to my junior engineers from a perspective of "we will need
       | to maintain this for years...".
        
         | exe34 wrote:
         | Or as I tell people, if you die, I'll have to maintain this, so
         | I want to make sure I know what it's doing and why.
        
         | Terr_ wrote:
         | > I've always tried to teach this to my junior engineers from a
         | perspective of "we will need to maintain this for years..."
         | 
         | IMO that kind of long-term phrasing can sometimes backfire,
         | because then the enthusastic junior engineer will go: "Ah! I'll
         | impress everyone by making the most flexible configurable
         | modular thingy!"
         | 
         | In other words, what TFA cautions against:
         | 
         | > The danger of the tar-pit is that instead of developing a
         | solution to a problem, you develop a tool for solving problems.
         | [...] situated right in the centre of some of the most
         | attractive real-estate in your imagination. Tools that solve
         | whole classes of problems in generic ways offer the potential
         | for vast improvements is productivity.
        
       | tudorw wrote:
       | Bring my yahoo pipes back!
        
       | jvanderbot wrote:
       | I may be an outlier here, but I'm always pushing back against
       | generalization. When someone reviews a PR and asks me to extract
       | an interface (in case we need to change this step?) I find it
       | really annoying. I know some people think that way first, and
       | it's not really the point of the article, but still.
        
         | adelineJoOs wrote:
         | I agree that it seems that some people are drawn towards
         | abstraction, while are are drawn to spezialisation. (Also in
         | learning, in PL class, I needed to see code samples and infer
         | the rules from there, others needed to see the rules and could
         | produce code samples from that).
         | 
         | I think that it is good to view generalization as a tool. Like
         | everything in software engineering, it is not an exact since
         | and is influenced by many factors etc. But for me a guiding
         | rule is: "When it is really clear that something will change in
         | the future, then it makes sense to generalize. It is clear
         | enough when you were willing to bet one week of your salary on
         | that the need for generalization arises within X time." (where
         | X is something less up to a year).
         | 
         | Mainly because this communicates intend to future code readers:
         | "Beware, this thing will likely not be alone soon".
        
         | nobodyandproud wrote:
         | The response for an "in case" is premature abstraction.
         | 
         | Unused abstraction makes reasoning about the codebase harder.
        
       | ninkendo wrote:
       | See also the Architecture Astronaut:
       | https://www.joelonsoftware.com/2001/04/21/dont-let-architect...
        
       ___________________________________________________________________
       (page generated 2024-05-05 23:00 UTC)