# Knowing when to delete code

DevFeed: [Knowing when to delete code](<https://devfeed.tech/articles/knowing-when-to-delete-code-21614.md>)

Original publisher: [Read original article](<http://miqu.me/blog/2016/08/16/knowing-when-to-delete-code/>)

Author: Miguel Angel Quiñones

Published: 2016-08-16T20:04:04Z

Content type: opinion

Language: en

Sources: [Miguel Quinones](<https://devfeed.tech/sources/miguel-quinones.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [Development](<https://devfeed.tech/topics/development.md>), [Application Development](<https://devfeed.tech/topics/application-development.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [development](<https://devfeed.tech/tags/development.md>), [legacy-code](<https://devfeed.tech/tags/legacy-code.md>), [refactor](<https://devfeed.tech/tags/refactor.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [regression](<https://devfeed.tech/tags/regression.md>), [rewrite](<https://devfeed.tech/tags/rewrite.md>), [tests](<https://devfeed.tech/tags/tests.md>)

## AI overview

An opinion article about deciding when to delete code in long-term projects. It discusses short-lived application code, how evolving products can make code legacy, and the trade-off between refactoring and rewriting, favoring small refactorings over large rewrites.

## Source excerpt

Much of the literature and writing related to sofware development focuses on the creation, new ideas, fresh ideas and things to improve in your next project. But when is it a good moment to delete the old stuff in an long term project? Here's my short rant about this; I recently deleted a chunk of code in my current project and just felt I wanted to write my thoughts. Short-lived code Working on application development field, it is very normal that some code is very short lived. If you're looking to build systems and generic components then you're generally out of luck. Most Application code is generally short lived. In my opinion we just need to know how to deal with it. Products evolve, ideas and markets change, and the code implementing those concepts has to change to reflect the direction of an application. If your code doesn't closely relate or express the domain of your application, you're bound to have design problems, miscomunication and likely many bugs. Application code is very likely to become legacy in a very short time. That time might be even less than 1 or 2 years. Legacy code There isn't consensus on what makes code reach the dreaded legacy status. The definition has changed since it's first introduction, and nowadays we generally consider legacy the code that we didn't write. See the wikipedia entry: ...source code inherited from someone else and source code inherited from an older version of the software Or another definition: Michael Feathers introduced a definition of legacy code as code without tests, which reflects the perspective of legacy code being difficult to work with in part due to a lack of automated regression tests Many programmers generally call legacy code anything that they didn't write. While this is a very harsh treament of somebody's effort and time, it will mean that your code will become legacy in very short time as well. Refactoring vs Rewriting Legacy code is often mentioned when refactoring. The effort of writing some piece o