[HN Gopher] Things You Should Never Do, Part I (2000)
       ___________________________________________________________________
        
       Things You Should Never Do, Part I (2000)
        
       Author : sealeck
       Score  : 15 points
       Date   : 2024-02-29 21:46 UTC (1 hours ago)
        
 (HTM) web link (www.joelonsoftware.com)
 (TXT) w3m dump (www.joelonsoftware.com)
        
       | hermitcrab wrote:
       | An oldie, but a goldie.
        
       | QuadmasterXLII wrote:
       | My guess at the problem: we all feel a sense of relief when the
       | codebase gets smaller, but making an existing, working codebase
       | smaller is really, really hard work. Deleting it and starting
       | over front loads all the reward
        
       | dang wrote:
       | Related:
       | 
       |  _Things You Should Never Do, Part I_ -
       | https://news.ycombinator.com/item?id=31122975 - April 2022 (7
       | comments)
       | 
       |  _It's harder to read code than to write it_ -
       | https://news.ycombinator.com/item?id=31117277 - April 2022 (2
       | comments)
       | 
       |  _Things You Should Never Do (2000)_ -
       | https://news.ycombinator.com/item?id=23725867 - July 2020 (83
       | comments)
        
       | cmollis wrote:
       | I always thought it was easier to read code than to write it.
        
       | dgan wrote:
       | Meh. I rewrilote our backend in about 3 month, and in the end of
       | rewriting another service. All good so far!
       | 
       | Sometimes stuff is broken so badly you better start over
        
       | onetimeuse92304 wrote:
       | I think people tend to want to rewrite software for the
       | psychological break from the old, bad and ugly thing they don't
       | want to have anything to do with anymore.
       | 
       | It is so easy to think "If only I could start everything from
       | scratch, life will be so beautiful and I will be so successful
       | and everybody will be happy. I will fix all the problems of the
       | current codebase and people will forever sing songs about how
       | amazingly I turned everything around."
       | 
       | What more frequnetly (much more frequnetly) happens is usually
       | some mix of:
       | 
       | * developers not really understanding why exactly the previous
       | version failed,
       | 
       | * developers not really understanding what actually worked well
       | in the previous version,
       | 
       | * developers completely underestimating actual amount of
       | accumulated knowledge in the old system that they now have to
       | replicate. Obviously, they only discover it along the way when it
       | is suddenly too late to fix the design to take all of that stuff
       | into account.
       | 
       | * developers not appreciating the fact they are in a much very
       | different (worse) situation than original creators of the
       | previous version. The creators of the previous version had time
       | to build the system and then slowly evolve it. But the current
       | team has typically a short time horizon to replicate _ALL_ of it.
       | 
       | * as the resources are shifted from the maintenance of the old
       | system to the development of the new, suddenly the clock starts
       | ticking and the stakeholders are impatient to see the result. The
       | pressure grows quickly and with it comes inevitable compromises
       | and technical debt.
       | 
       | * at some point development team is told they have to start
       | maintaining the old app. The resources devoted to the rewrite
       | shrink, the work grinds to a halt. I have seen many more systems
       | that have been in a state of perpetual migration than I have seen
       | ones that have been successfully completed rewrite.
        
       | glimshe wrote:
       | I keep hearing this nonsense over and over. I've led two full and
       | very successful software 50-100K LOC rewrites, both with the team
       | and stakeholders who had a lot of experience in the problem
       | space. We replaced unmaintainable systems by a much fresher, MUCH
       | faster codebase. They used largely boring and reliable
       | technology. Rewriting 1%, 10% or even 50% would make no sense and
       | essentially get us little or nothing.
       | 
       | Yes, you need to know what you're doing if you plan to rewrite
       | anything, and make sure that the people who know the little
       | legacy details of your system are around, but it's absolutely the
       | right thing to do in many situations.
        
         | cyberax wrote:
         | 50-100K LOC are less than the amount of code for the build
         | system in a couple of projects I worked on.
        
       | CoastalCoder wrote:
       | The HN story immediately above _this_ one is  "A Social History
       | of Jell-O Salad".
       | 
       | A perfect pairing.
        
       ___________________________________________________________________
       (page generated 2024-02-29 23:00 UTC)