I am very cognizant to avoid replacing and rebuilding just for the sake of it. I think the second system effect describes this bias well:
The second-system effect (also known as second-system syndrome) is the tendency of small, elegant, and successful systems, to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.[1]
In The Mythical Man Month Fred Brooks discusses the idea of The Second System Effect. The Second System Effect is the tendency for a project manager or software architect to err on the side of overembellishment when planning their second project. In large part, this is due to the fact that the architect has to exercise a great deal of willpower during the first project by keeping scope under control while constantly thinking about all of the really great things they want to add to the next project. Personally, I think the perils of The Second System Effect can exist well beyond your second project and this is something we always have to be on guard against.As an architect, your early projects will be like quicksand. They will pull at you in ways that you haven’t experienced before and it is important to have an anchor that can keep you grounded and on track. This is why it is imperative that you seek out the mentorship of someone more experienced and smarter than you to help guide you through your early projects. A good project mentor will provide a safe place for you to express your thoughts and ideas about a project and they will give you honest, candid, and sometimes difficult feedback.A root cause for problems is when the team latches on to an Utopian vision of version 2, such as the desire to make the new software “flexible”. In this scenario everything is abstracted to the nth degree. For example, instead of data objects that represent real-world entities a generic “item” object is created that can represent anything. One flawed idea is that we can build in so much flexibility into the software to anticipate future needs, that non-programmers will be able to just configure new capabilities. Often one goal such as “flexibility” overshadows the effort to a point that the resulting software doesn’t work.
Also published on Medium.