[z3t4]

Anyone else feel sad when you remove a bunch of code? All those man-hours it took to write that code, and now I'm deleting it all. I believe it's called sunk cost fallacy. I often wish I had a time machine so that I could go back in time and say, hey, this will all be deleted a year from now, go with the other solution instead.

[Jtsummers]

Nope. One of my first experiences with removing many lines of code was in college. It was a compilers project (we had to hand-write it, no YACC or anything). I had written about 10k lines of code in a flurry of activity, and discovered some really gnarly bugs.

I spent a day with just a pencil and paper, considering each detail of the algorithms and came up with several key insights which reduced the whole thing to about 1k lines of code. The reduction was a combination of C macros (which I wouldn't use today, but I'd use higher-order functions to accomplish the same thing now) and just smart generic code (no special handling of an add operator versus a multiplication operator, they were both binary operators; differentiating the output for each case happened in one place at the end).

That was when I found out I liked deleting code. I'll happily reduce a code base by 90% if the result is clearer and easier to maintain or extend.

[jspash]

I experience the opposite reaction. I'm elated! Especially when a conditional can be removed/refactored. That's 1/2 as many tests. 1/2 as many possibilities for something to go wrong. As long as the functionality remains the same (or simpler) I love to delete code. Especially my own.

[iamatworknow]

I don't get sad when that code is deleted. I get sad when the people deleting it bash it as being "bad code", especially when they are new hires who don't know any of the context behind why that code is the way it is. Nobody wants to write "bad code", but every code base has some. Thankfully, with time and experience, developers usually mature from "who wrote this trash?" to "this code served its purpose, but we can make it better".

[jariel]

Accept that it's inherently an iterative process, then you don't think 'sunk cost'.

And then 'getting rid of code' is the most wonderful feeling in the world.

Getting rid of unneeded code is like clipping toe-nails that are way too long. (It must be done!)

It's like cleaning a disgusting floor in the bathroom (it can't wait).

It's like fixing ugly grammar and spelling mistakes.

It's like sanding and painting that old fence the really needed some attention.

[collyw]

Not at all.

If its taking 100 lines to do something and I can rewrite in 10, then that's a lot less places for bugs to hide. That's less than one screen of code for the next person to read / comprehend. In most cases its a win (though I will admit that sometimes comprehension is easier with less concise code).

[Sharlin]

If the code solved the original problem, as understood at the time it was written, then it was not written in vain even if changing requirements or improved understanding eventually make it redundant.

[downerending]

Nope. I liken it to exploratory surgery. Towards the beginning, I'm pulling everything apart, writing scaffolding to try things out, discovering along the way what's needed and what's not.

At some point, I close the patient, discarding a lot of that. At the end of the day, ideally it looks pretty minimal--just what's needed and no more.

[jborichevskiy]

Somewhat, but I feel better understanding that time/code was spent understanding the problem better, and with that knowledge I'm now able to make something cleaner/simpler/more concise.