The second-system effect refers to the tendency of small, elegant, and successful systems to have elephantine, feature-laden monstrosities as their successors
When starting work on a follow-up project that will share the same codebase as the previous project, how do you control the second system effect? How do you stop yourself going overboard on rewriting flaky systems? How do you restrict "wouldn't it be cool if..." new features?
I find one of the biggest factors is complacency from familiarity with the codebase. It can be very easy to add new features by "hacking" together systems that you know inside and out. However the short-term gains are outweighed by the spaghettification of code a few iterations of this approach can produce. How can you coerce programmers to design and implement features properly, when the "quick hack" solution is so tantilising?