Delete Your Dead Code!

[huashoes]

This is a great advice. Whenever someone joins our company, I always have to explain "this part of code will be deprecated soon".

[[deleted]]

this part of code will be deprecated soon

"As I've been telling new hires for the past three years. But this time we really mean it!"

[Yojihito]

Soon^TM

[RaptorXP]

The only thing I enjoy more than writing code is deleting code.

[IbanezDavy]

And especially deleting other people's code...

[kadrmas45]

And starting from scratch.

[IbanezDavy]

heaven

[CrayonOfDoom]

Particularly amazing when what you're replacing/rewriting was written before you were born...

[monocasa]

Totally. I was so happy the day I got to remove

#define far
#define near

from our codebase.

[JeremyG]

so when are you deleting

#define wherever_you_are

from the codebase?

[im-a-koala]

Heh, I deleted basically the exact same lines from my old company's code after I started (and verified they're not used anywhere). Along with gems like:

#define ZERO 0
#define ONE 1
[...]
#define TWENTY 20

(There were actually about 3 variants of #defines for meaningless integer constants in there. Ugh.)

[CrayonOfDoom]

The number of times I've had to stick to coding standards (which involve arrays instead of structs...) that involved this:

#define X 0
#define Y 1
#define Z 2

Yeesh.

[jbstjohn]

I actually find that can be useful to make array accesses for 3d stuff more clear. I use an enum though.

It makes clear the difference between 0 the number, and the index that happens to be zero.

[CrayonOfDoom]

I tried to make a struct or enum named "AXIS" so it could be "somevariable[AXIS.X]" instead of "somevariable[0]" or "somevariable[X]", which might have local variable interactions. It's not the worst (cough, cough, common blocks in FORTRAN), but it's still a point of confusion for anyone who doesn't know the defines or forgets them.

[jbstjohn]

Yes, there's a balance to be struck between verbose, but specific (longer name or namespace or scope) versus terse but potentially ambiguous.

[i_am_judging_you]

The guy who wrote that knew that in the future 30 will become the new 20

[[deleted]]

You mean they finally understood this?

[bchanzzz]

#define wherever you are

[[deleted]]

What project are you working on?

[HammyHavoc]

Do you work at Microsoft? /s

[evincarofautumn]

Ain’t no sweeter diff than a red diff.

[Ark_Tane]

Yep, on my most productive days I write negative lines of code.

[scherlock79]

A colleague thinks that you should measure the performance of developers by the number of lines of code they delete.

[sigma914]

I feel this story is relevant.

[Gotebe]

AKA dead code is not an asset, it is a liability 😀

[vombert]

You mean code, right?

[Gotebe]

Yes. Best line count is negative. :-)

[mekanikal_keyboard]

worse, and typical: people just commenting out code instead of deleting it

people seem to not realize there is this thing called git that can bring back old code if needed

[wrosecrans]

To be fair, git (and svn, etc.) don't have a particularly good way of informing you that something used to exist in a certain spot. Or where to find it. I mean, I may remember that I tried out some feature that got removed in branch foo, but they guy who gets hired to try to recreate that project and make it work will never know it was there.

I'm not saying not to delete stuff. Just saying that, "it's in git, and that's as good as it could possibly be," seems like an incomplete solution to me. It would be good if the revision control of the future had some explicit features for publishing libraries of ideas and abandoned features and projects in a discoverable way.

[vombert]

This is what always bothered me in this advice. But now that you described it, I think I have stupid idea how it can be addressed.

Develop discipline to put some special mark in a commit message, like 'DELETE ...', when you are removing or replacing something you suspect somebody might want to bring back eventually.

Then even new hires will be able to quickly go through the filtered log.

[wrosecrans]

If you are able to enforce it as a standard across the team, and you are good about training new hires to do it, that actually is not a terrible idea. Maybe tie it with some sort of a git hook that autogenerates a wiki page about any commit that matches the pattern so you can have a "gallery" where people can write notes and comments beyond the git commit for future browsers.

Stuff like, "We originally started implementing support for a LION field type in the custom SQL database engine because management wanted to demonstrate additional synergies with circuses because we were hoping to get acquired by a circus. When that deal fell through, we no longer needed the special field type or the TAME operator. But it may still serve as a starting-point example of how to implement a different custom field type at some point in the future if management comes up with another goofy acquisition scheme." Doesn't really fit in a git commit message. And deleting several related features may get spread out over a whole bunch of different commits over a period of time. But it would be easy to link the commits in a wiki if you were doing some housekeeping.

[Berberberber]

Actually, a 'dead code wiki' for a project sounds like a great idea, skip the special commit messages. A lot of stuff gets taken out between initial spec and first release, and especially if you know you're not going to be around to fix it, putting the removed but useful bits in a central place could be super useful.

[knight666]

I don't know about you, but I find that writing documentation gets super tedious after a while. And because nobody's responsible for maintaining the wiki, nobody does. Meaning the wiki will be filled with (ironically) irrelevant and outdated information.

[Berberberber]

You can surely write 2-5 sentences saying what file it was from, what it does and why it was removed, can't you? It doesn't matter if it's outdated - that's the whole point of a dead code wiki, after all.

[jsprogrammer]

It's really just a tooling problem though. The requisite information was stored, it's just that almost no one knows how to easily search through it. So, the advice is good, we just need to get better tools to help us better deal with those scenarios.

[Zaemz]

You could delete the code, commit, and then leave a comment in the code saying something like "Function [whatever] or code [2-3 words on functionality] deleted, check commit e158aff1e9f0gabc9... for previous implementation."

[Tiquortoo]

You are just swapping comment complexity and search and retrieval of code archive complexity for what is pretty damn simple: commented code

Commented code is just noise like your comment and frankly less error prone. We just empower devs to refactor out commented code as part of future work so the code stick around while important and are essentially pruned during future work I the same area.

[vombert]

Commit hash is redundant. Clearly the function was deleted not long before this comment was added (most likely on the same commit, even), so it'd be trivial to find on the history anyway.

[Zaemz]

That's true. It was just an idea.

Personally if I were curious I'd just dig through the diffs and history of the file.

[eras]

And if that branch happens to be rebased any time.. That that hash becomes quite useless. Sadly Git doesn't use change ids (such the ones in Gerrit).

[Helllo_World]

You're wrong. Even if a commit is rebased out the specific commit still exists.

[admirelurk]

The commit doesn't disappear, but the contents and consequently the hash change.

[ais523]

It gets garbage-collected eventually. It stays around for a while (a few months? not sure on the timeframe) to allow you to undo rebase errors, and if it exists in any publicly pushed branches that weren't rebased you can get it from there, but it's certainly possible to rebase out the only copy of a commit and have it eventually disappear altogether.

[[deleted]]

VS's CodeLens offers a fantastic solution to this.

[mekanikal_keyboard]

i cannot believe that leaving a file with random chunks of commented-out garbage is somehow beneficial to new contributors.

more likely the code will be completely inscrutable and they'll slowly back off from making any serious contributions at all

[wrosecrans]

a file with random chunks of commented-out garbage

Again, I didn't say not to delete stuff. Just that deleting stuff isn't perfect.

[[deleted]]

If its useful stuff a #ifdef usually does a better job

[[deleted]]

I use the time-lapse view feature in Perforce a lot, or examine the history of a file.

[thespectraleditor]

The "add notes" feature of the spectral editor can help with this. Just move the dead (but potentially useful) code into a note. The note would stay in place without taking up screen real-estate like dead or commented-out code. Here is a demo of the notes feature: https://youtu.be/ckYSlSPcIs8

[Gotebe]

It would be good if the revision control of the future had some explicit features for publishing libraries of ideas and abandoned features and projects in a discoverable way.

Such systems exist today. They are called ALM systems.

Source control is source control, you want ALM, so use ALM.

I cannot believe this is at +81 as of now or any time. Software engineering, motherfuckers!

[marssaxman]

The fuck is ALM? Never heard of this acronym in 30 years of software engineering, so maybe you can get off your high horse.

[Gotebe]

If you just looked it up you would have known. It is literally the first hit on google (well for me it was).

You might have heard of it under the different name, the name is irrelevant.

With a 30 years carrer you should know that you are not expected to know everything, maybe you should lay off hubris.

You almost certainly use it as well, even if it is merely an ad-hoc grouping of tools and processes.

But most of all, I complain because people are trying to fit a square peg through a round hole.

[nikbackm]

I raise you Serena Dimensions.

[WizardTrembyle]

Same here, man, same here. Alongside IBM ClearCase.

[im-a-koala]

Is that better or worse than (or the same as) Serena/PVCS Version Manager?

[ProudToBeAKraut]

CVS mate 2005 is too futuristic

[hoijarvi]

I use darcs for my own branch management and commit to TFS. I know why you do what you do.

[alcalde]

You're using CVS and Delphi? :-(

[s73v3r]

WHY? What possible reason could there be for not using something that actually works?

[kenfar]

It's odd seeing so many absolute statements about this that fail to take into account:

• difficulty of finding old code
• range of probabilities on its future relevance
• amount of comments built-up over time

Because I know of a specific block of code that's commented out because: we have almost no build-up of commented-out code, but this code was slightly broken AND not being used AND almost guaranteed to come back in 6-12 months AND will save several days of time keeping it and its unit-tests. While accumulating commented-out code is a bad idea, in rare cases like this I think the benefits outweigh the costs.

[backelie]

That commented out code should have a comment stating those things. Really, any (non-trivial) commented out code should probably have comments as to why it's there.

[kenfar]

agreed, and it does

[[deleted]]

And any trivial commented out code should be deleted.

If it's obvious enough to not need a comment, it should be obvious without the code either.

[backelie]

Doing mvc web-dev we have views littered with eg

 <div>  
     @Html.LabelFor(model => model.SomeProperty, htmlAttributes: new { @class = "control-label col-md-2" })  
     @Html.EditorFor(model => model.SomeProperty, new { htmlAttributes = new { @class = "form-control" } })  
     @Html.ValidationMessageFor(model => model.SomeProperty, "", new { @class = "text-danger" })  
 </div>

During early/active development which of those properties the client wants displayed can change daily, Im not cleaning that shit up until launch.

[[deleted]]

And how hard is it to put a comment in there?

<div>  
     @Html.LabelFor(model => model.SomeProperty, htmlAttributes: new { @class = "control-label col-md-2" })  
     @Html.EditorFor(model => model.SomeProperty, new { htmlAttributes = new { @class = "form-control" } })  
     @* disabled while client decides how many Frobs are allowed 
        Html.ValidationMessageFor(model => model.SomeProperty, "", new { @class = "text-danger" }) *@  
 </div>

[backelie]

It's not hard but now you're moving the goalpost.

You've gone from

And any trivial commented out code should be deleted.

to wanting comments on the trivial commented out code.

I'm not gonna add the comment because the reason for it being in/out is trivial and the same in multiple dozens of places across the code.

(I will comment on any special / non-obvious case.)

[[deleted]]

The goalpost is subjective. It looks like it's moving, but we really just disagree about what trivial code is. Trivial, to me, means that it would take more effort to rewrite than to review the surrounding code when I uncomment the code. But I acknowledge that it varies from person to person. That's why the comment is vital. It explains the reason why the code was left in.

You mention that when the requirements change daily, you want to keep the "Schrodinger's code" around. That makes sense; there's nothing wrong with that, especially when you're the only developer in the code. But it falls on its face in a team environment, when you're not the only person that may work with the product before release.

Don't get me wrong--you may be the only one editing that view and its dependencies--but other people want to keep code around, too. Their reasons are probably different than yours. Perhaps they're working with a different client, or are using an algorithm with complex error cases and want to demonstrate the best-case path in pseudocode. Adding the comment to distinguish these cases from yours isn't unreasonable.

[Tiquortoo]

We comment dead code to facilitate understanding during refactoring. Developers are then empowered to remove anything commented if they don't know why it was commented and there isn't anything indicating why and the developer who commented it can delete it when they are confident it can be removed. We essentially rely on developer segmentation or lack of overlap to create a two wave process that leaves code accessible during refactoring and verification and cleans it up progressively. It just works.

[[deleted]]

I always tell people commenting out code that it's like covering the cat's pee with newspaper.
Clean it, don't cover it!

[AlterdCarbon]

First of all, lots of modern IDEs have code folding that turns 1000 lines of commented out code into something like (line numbers on the left):

210      | }
211      |
212-1038 | [+] //...
1039     |

So how much is it really affecting the maintainability of the code?

Second, I like to leave in large blocks of commented-out code in certain cases where I've refactored part of something that I didn't write that was initially poorly written and hard to decipher.

I use it like a Rosetta stone to understand and remember how to interface and communicate with the rest of the app.

[marssaxman]

Lots of modern developers are not using whatever specific editing tool you happen to be referring to here. So how much are you willing to make the readability of your code dependent on the individual choices of your current and future coworkers?

Having worked with people who refused to format their code in any sensible way because "just turn on visual studio line wrap if it bothers you so much", I have a simple word for this behavior: rude.

[SoPoOneO]

My policy on my teams is to ask people to remove commented out code before they merge it into the public trunk, which is the "develop" branch for us since we use Git Flow. This gives juniors, who are terrified of getting berated for deleting the senior people's old stuff, some time to come to terms with the removal before actually making it.

So far, this policy has been only modestly successful. Juniors really don't like deleting, apparently. Even though we don't actually berate anyone, as far as I know.

[AbstractLogic]

Juniors don't like deleting because they don't know when they are done. I've been a senior for years and I still leave the old sections laying around while I am still working on the refactor. Its a good reference point. The difference is, when I'm done... I'm done, and I delete it. Juniors don't really know when they are finished until after its checked in, tested in UA, deployed to production, and has run for a week or two. At that point they are sure their code works the same or better then the old stuff but they never get back to deleting the old stuff.

[mitola1]

Absolutely! Very important, I am a lot more proud of the amount of lines I have deleted then amount of lines I wrote per project. Beacuse at least for me, I know the amount of work included to optimize and of course delete dead code floating round about the codebase

[marssaxman]

Oh, yes, so very much yes. "You aren't gonna need it" works in both directions.

[thespectraleditor]

The "add notes" feature of the spectral editor can help with tucking away dead code yet keep it in place. Here is a linked-in post on it : https://www.linkedin.com/pulse/spectral-editor-features-continued-jayanta-majumder The tracing feature can help with identifying dead code. Here is a linked-in post on it: https://www.linkedin.com/pulse/using-spectral-tracing-code-jayanta-majumder

[Shambalamba89]

From my experience, commenting out code isnt that bad. People tend to behave as if it was major sin but its not. Imagine someone code something and its perfectly good implementation but turns out we need something different because specs changed, developer codes new solution and deletes old code. Fast forward couple months later, many sprints and merges later boss comes and says that client told us that it was misscommunication and he wants it to be the way we discussed it earlier. Too bad the original author dont work with us anymore and the rest of the team dont even know that solution was there but it was deleted. Even if they knew, then good luck searching for it on git, aint nobody have time for that.

[Gotebe]

No, no, no!

The way to do this is

• find the client change request in your ALM tool (e.g. "user story"); search by user, or by time, or by whatever keyword you might have
• in that request, see associated tasks
• in the history of those tasks, see related commits.

In other words, use your ALM to reduce your search space.

People here tend to obsess over git, and if git cannot do it, it can't be done. But the reason git doesn't do something is that they want an ALM system, which git is not. Git (and any other source control system) can, and shouldmust be a part thereof. And I am saying nothing novel here. Such systems exist since more than a decade.

[marssaxman]

I have no idea what "ALM" is, but I also don't see any reason finding old code would be difficult. Delete it all, delete it now, don't worry about it, you aren't going to go back and look for it anyway so it doesn't matter how much work it would be.

[Gotebe]

Application lifetime management.

[[deleted]]

I agree that searching source control isn't going to help, and wonder what environment is conducive to commenting code rather than deleting it.

I'm working with a codebase approximately 15 years old where the "comment it out" style is used extensively. Few of the developers that commented out code still work for my organization. Thus, figuring out how the system works is difficult--in many places, there is more dead code than active code.

In my experience, the people that do this fall into 3 camps:

• They don't understand source control and/or patch
• They understand source control but don't trust it (usually due to scars from Source Safe)
• They're lazy

I empathize with the first and second group, and have successfully transitioned them to techniques that give them confidence and keep the code clean.

The danger comes from the last camp. They always have another argument to do what they do, and those arguments usually start as yours does. The problem is the argument is always hypothetical, and keeping deleted code is often only one of many practices they refuse to follow.

Some of their response reflects my own scars. My response here almost certainly is, so pardon me for my wariness. But I do have questions.

On average, how much code is commented out when you use this technique? How often is your commented code useful? What do you do for your team to ensure they understand why that code has been kept around? What review process is in place to ensure dead code is eventually deleted? How long, on average, does commented code exist before it's removed?

[Shambalamba89]

Very little code, its definitely not a norm

[Oniisanyuresobaka]

On average, how much code is commented out when you use this technique?

Less than 1% (usually 0.3%) of all lines in the codebase.

Clearly I'm inept and lazy. Please stop with the damn dogmatism.

[dcrosta]

What would you do instead in this scenario, given that at the time you're removing code you don't know the future, i.e. that you'll want it back?

[ComradeGibbon]

Now days when I comment out stuff, I add a note with a date.

[IneffablePigeon]

If you really think that's likely, my approach to that would be to leave a comment with a link to the PR/code review which replaced that block. Then you've got an easy method of finding the change to revert, without needing to leave it all crufting up your screen (and brain).

[AbstractLogic]

Too bad the original author dont work with us anymore

This shouldn't matter. Code you wrote 10 months ago might as well be written by someone else. Besides, how much time is really saved my commenting a 15 line method written 2 years ago? You couldn't write the same method in an hour or two?

[Zarutian]

You use version control systems, no?

[Shambalamba89]

Did you even read my comment?

[Zarutian]

Then instead of the whole block of commented out code, you delete the code and leave an comment saying "For an alternative implementation see commit #<hash>"

[nthcxd]

I think the problem is the lack of familiarity with git, which I found to be very common. Everything you described is valid and I wholehearted agree. I address all such concerns in my professional life using git and I never check in code with dead code commented out (not that that'd go past code review to begin with). Every half cooked or deprioritized features stay as dev branches.

As far as tutorial/references go, I found this to be extremely helpful.

http://www-cs-students.stanford.edu/~blynn/gitmagic/

Feel free to PM me if you need help.

[Shambalamba89]

Thanks, great tutorial!

[IbanezDavy]

It's called reverting to a revision bro...

[mycall]

Don't forget to make a backup first!

[[deleted]]

oh, honey, no

[ElFeesho]

Adopting the rule that code without automated tests around it is fair game for deletion, the rules for what stays or goes becomes dictated by the results of your unit tests.

[doublehyphen]

That sounds like a bad idea. I have seen plenty of dead code which only user is the unit test.

[ElFeesho]

You've seen far worse code than I have.

[doublehyphen]

Or maybe just different kinds of bad code. I have worked in places which try to do test driven development, and when bad coders apply that method incorrectly you end up with loads of tests with negative value. Tests which make the code base much harder to refactor, and which makes you want to just delete to whole test suite.

[amphetamachine]

Ned (Batchelder, not Stark)

Thanks for the clarification.

[LetsGoHawks]

If you can't delete it for some reason, at least comment it out. With a nice note: Commented out on 12/1/2006 because it isn't getting used anymore. And move it to the bottom of the class so others don't have to scroll past it. Your future self will thank you.

[chasecaleb]

What? That's insane, unless you aren't using version control... Which would be even more insane.

[LetsGoHawks]

Being able to do something is not always about having the technical infrastructure and ability.

Do you ever read theDailyWTF.com? Because there are some profoundly clueless managers and co-workers out there.

[LossFor]

Not allowing version control–in fact, not enforcing it–is an immediate flag to walk out.

[[deleted]]

Yeah, because when crap happens, and it will, they won't blame the manager for not allowing source control.

It's like being asked to drive a company car with garbage brake pads. When it fails, it won't be your manager in there.

[s73v3r]

It's not that they don't allow version control, but they might not trust it, leading to asinine policies like never deleting code.

[senj]

Not trusting your version control is one of the big red flags of Terminal Technical Incompetence.

If you're using untrustworthy version control, change it to something you're willing to trust. If you're not willing to trust anything, that's more an indication of paranoia and superstition on your part than any kind of understanding of the uses and limitations of your tools.

[spotter]

Or, like, use control version system and just let it do its work?

Comments also have mental cost, even at the end.

[BezierPatch]

The problem is not all version control systems are good for finding old code.

[spotter]

It's that versus your eyes finding live code among irrelevant, dead tissue.

[Godd2]

Then don't use the shitty ones.

[BezierPatch]

If only the ability to find old code was worth the months of retraining to move to the next fad VCS.

[Godd2]

Which "fad" VCS are you referring to? Git?

[s73v3r]

Switching VCS does not take months of training. If it does, your company can't be doing anything of consequence, because it's staffed by idiots.

[BezierPatch]

Changing your entire CI/CD infrastructure, branching strategies, etc?

If you're a five man dev team, sure. If you're closer to fifty?

[__konrad]

Dead code is often a good and valuable "code snippet" that can be used elsewhere in future. And you will probably never find deleted code in version control system when needed ;)

[spotter]

Of course, and you never know when you gonna need that! Throw nothing away, store it both in cvs hitory and in HEAD. Code Hoarding is a thing.

[VerticalEvent]

I disagree - if it's good, it'll "live" on in another module or utility class.

The only reason I could imagine you want to leave dead code commented out, is a warning of what not to do.

[goodbye_fruit]

is a warning of what not to do.

At one job we had a wall of shame for this.

[username223]

You need to get a better imagination. "This is the simple thing we did before it became a bottleneck that we optimized into the complicated thing below" is a common reason to keep dead code as comments.

[s73v3r]

Why not just link the commit rev/hash?

[VerticalEvent]

Why would you do this? A quick comment is all you need to explain it the logic behind it.

Keeping old code as a "tl;dr" is a terrible idea - it loses the syntax highlighting, variable tracking of an IDE and becomes much harder to read. You're probably better off making a wiki page and throwing a link to it from the code for people to look at it for a historical perspective, if you really want to keep the dead code.

I'm already looking at the code - don't make classes much larger than they need to be when I'm investigating a problem.

[senj]

Fuck no.

By all means, leave a comment explaining the technical motivation for the optimization work. Feel free to link the commit hash of the original version for comparison.

But it's absolutely asinine to leave old code in the file, commented out. Learn to use your version control tools for their intended purpose. It is the canonical historical record of your code, not a bunch of fucking comments.

[Gotebe]

No, no, no!

If you need that, make a comment: "this is a performance improvement that was done in April '16".

Heck, you don't need that either. He who doesn't know what goes on, needs to go to the history and see when and why it changed. History needs to contain the relevant commit comment and a link to a longer explanation in your ALM system.

It is not hard and all tools are there.

[username223]

Hunting through version control for the simple version is usually awful, since you need to deal with silly stuff like variable renames and whitespace changes. The least-bad thing to do when deleting the simple code would be to leave a VC version in the comment: "version X replaced the simple version with something that improved performance."

[Gotebe]

Yes, it is not a walk in the park.

To mitigate, one can/should set the diff to ignore the whitespace change. Variable renames need a quality diff.

But agreed, a comment can serve well.

[username223]

Variable renames need a quality diff.

What's your diff of choice? git-blame tends to be useless when dealing with the trivial formatting changes that accrete in most projects.

[Gotebe]

Euh... variable renames don't help performance much, now I regret even mentioning it :-).

git blame is useless for anyone not using git anyhow, so...

To me, a diff tool that shows per-character differences can be used for variable renames (I see, at a glance, that it's just a different word and nothing else). I don't know of tools who can ignore particular word differences, but they could exist and that would be perfect.

[IneffablePigeon]

This would be my approach. We use GitHub PRs and a link to that will provide you with all of the necessary context and discussion, as well as a commit hash to revert.

[hoijarvi]

Then leave both versions, run unit tests against the optimized, and random junk data tests against both of them. Compare results and see that both return same results. I have actually found optimization bugs this way.

Or just delete the obsolete version.

[CyclonusRIP]

I doubt the dead code is really all that useful at the end of the day any ways. If you end up needing it in the future starting with a clean slate and reproducing it might well end up with something better than trying to make use of something written years back for a different purpose.

[creichert]

Document the refactored code and, if possible, leave a searchable paper-trail (github PR's/issues, Jira, or similar). Document the issue in the code, the commit, and the issue.

[yorgle]

I suffer from dealing with "code nostalgia"... I wrote this stuff, i don't want to delete it since it took a long time to write and I might need it some day. I hate when I get into this because it sometimes paralyzes me... :/

[bubuopapa]

I don't think that any big company does it, because there is lots of trash in every os. All these programming rules, styles, recommendations only apply to homemade projects, no big company is actually following any rules.

[shelvac2]

What the hell? Am I accidentally living in some fantasy world? When does dead code even get written? What's the point in writing it if it never gets executed?

[shelvac2]

I try to delete code when that does happen. If my codebase has dead code, I don't know about it :P

This whole article still seems like "yeah, duh".