# Write Less Code

DevFeed: [Write Less Code](<https://devfeed.tech/articles/write-less-code-24946.md>)

Original publisher: [Read original article](<https://codeahoy.com/2016/06/03/write-less-code/>)

Author: umer

Published: 2016-06-03T00:00:00Z

Content type: opinion

Language: en

Sources: [Code Ahoy - Articles](<https://devfeed.tech/sources/code-ahoy-articles.md>)

Topics: [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Code](<https://devfeed.tech/topics/code.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [code](<https://devfeed.tech/tags/code.md>), [programming](<https://devfeed.tech/tags/programming.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [software](<https://devfeed.tech/tags/software.md>), [source](<https://devfeed.tech/tags/source.md>)

## AI overview

The article argues that software projects become difficult to maintain when developers add unnecessary, tightly coupled, and over-engineered code. It describes a refactoring effort in which a module was reduced to less than half its original size and advocates writing as little code as possible.

## Source excerpt

Not too long ago, I sat down to 'clean up' a project that I inherited. I was given the reins of the refactoring efforts because the project has had several bugs in production. It was stuck in a vicious cycle where fixing old bugs would introduce new ones. So I dived into the source code one weekend and the problem soon became evident: the project was a big, hairy mess. I use the word big because there was lots of unnecessary, redundant and tightly coupled code. By hairy mess, I don't mean that the code looked amateur or was full of shortcuts. In fact, the problem was quite the opposite. There was too much magic and everywhere I looked, I saw clever and grandiose design practices that had no relationship with the actual problem that the project was built to solve. Things like reflection, aspect oriented programming, custom annotations were all present. The project was an over-engineered beast. To put it into perspective, after the refactoring was over, the module was reduced to less than half of its original size. I'm sure the developers who wrote the project did so with the best intentions, but their clever tricks turned against them. They spent a lot of time on periodic maintenance and fixing bugs. The clients were unhappy that the software was full of bugs. The developers felt like shit because everyone was always complaining about the project. But who's to blame for their misery, for the long hours they had to work to fix the bugs and get no satisfaction out of their jobs? No one else to blame other than the developers themselves. One of my favorite bloggers, Jeff Atwood, wrote that the best code is no code at all: It's painful for most software developers to acknowledge this, because they love code so much, but the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported. Every time you write new code, you should do so reluctantly