# Someone Wrote that Code on Purpose

DevFeed: [Someone Wrote that Code on Purpose](<https://devfeed.tech/articles/someone-wrote-that-code-on-purpose-21044.md>)

Original publisher: [Read original article](<https://jakeyesbeck.com/2015/10/04/someone-wrote-that-code-on-purpose/>)

Published: 2015-10-04T12:00:00Z

Content type: article

Language: en

Sources: [Jake Yesbeck](<https://devfeed.tech/sources/jake-yesbeck.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [engineering-culture](<https://devfeed.tech/topics/engineering-culture.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [code](<https://devfeed.tech/tags/code.md>), [developer](<https://devfeed.tech/tags/developer.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

## AI overview

The article argues against assuming that older code is wrong or was written carelessly. Developers who modify existing software should first understand its original context, internal behavior, and interactions with external services, because removing or changing obscure code without that understanding can cause severe consequences. It recommends assuming that the original author was competent and treating legacy code with caution before refactoring it.

## Source excerpt

One of the great misconceptions of software engineering is the belief that "any code written in the past is probably wrong". For some reason, an accepted mindset (usually among junior developers) is that older code was written with haste or by someone who did not fully understand the problem at hand, invalidating its existence. A multitude of rationalizations may arise when the thought of refactoring software from the ground up is an option. After all, the person who wrote that code may not even be around anymore. They could have just been learning the language, surely that is a valid enough reason to completely decimate their work. What possible justification could there be for the opposite? The code just feels wrong, and I, the new domain expert, will rectify this situation! The Devilish Details A person who stumbles on older code can not possibly have the same level of understanding as its original author. Do not misunderstand, it is completely possible that the original author had an insufficient amount of knowledge when writing the code; however, if details have been lost between code inception and re-discovery, removing that code could have dire consequences. How dire could they be? Well according to a recent Bloomberg article, it could be millions of dollars. According to the article: The Core Engineering developer did not understand that the changes he made to the code sequences would affect the directed ISOs generated by Latour's trading algorithms. The key words to take away here is that the developer literally did not understand the code. The developer that made this mistake needed to simply understand the code that he or she was editing. However, due to time constraints, inexperience, or just plain arrogance, that crucial understanding was never reached. The small yet significant details of how the code worked within itself and with external services were never discovered, leading to a catastrophe. Assume Smart People Wrote It A simple rule that may help