Kill Your Darlings

In software design, when you find yourself feeling particularly proud of a neat little bit of design or code, stop and ask yourself how someone who didn't give birth to it will regard it. If it turns out to be overwrought or too slick for the need, you should probably kill your darling and replace it with an ordinary solution that others can actually use, and not just marvel at.

Read over your compositions, and wherever you meet with a passage which you think is particularly fine, strike it out. -- Samuel Johnson

Die, die, die my darling, close your pretty eyes. -- TheMisfits?

William Faulkner is said to have advised writers to kill their "darlings," those little bits of glitter a writer thinks are simply marvelous. To the reader lacking that maternal attitude, they are at best distracting, at worst a reason to stop reading.

Darlings are sometimes characterized as being "ever so clever." For an example, the phrase "ever so clever" is ever so clever.

For a broader treatment of the issue, see EgolessProgramming. -- JohnDouglasPorter

Isn't this cured by PairProgramming? -- NissimHadar

Sometimes the pair reinforces the cleverness.

Perhaps this tendency is offset by CollectiveCodeOwnership.

Maybe the saying should be "Distrust Your Darlings." One of my Java teachers gave a single lesson on returning to a particular object a few days after successfully finishing it, and rewriting it along another way. Or another five ways, if you could think of them. He thought that writing easily-updatable code was all about making the problem the focus instead of the solution.

What if the part you are proud of actually isn't bad? For example, you're working on a class and determine there is some code that is shared with another class so you pull it up into a superclass. That seems like the sort of thing you might be proud of but that should also be kept.

If you're pretty satisfied with it, leave it in. If you're really really proud of it, it's probably got to go. The difference is in your emotions.

I'm inclined to never let emotions cloud my judgment. Sorry. It's one thing to be proud of something and then delete it because there are good reasons to do without it and your pride is no reason to keep it in. It's something else altogether to delete code because you are proud of it. If I had to do that then I'd have to delete entire programs which I am really really proud of, despite the fact that they are quite useful.

I'd amend this advice to say, "KillYourDarlings - if necessary." -- BlueHat

You can always misconstrue good advice if you really want to. -- BlueHat

The implication of KillYourDarlings is that you develop an emotional attachment to your clever piece of code (being proud of it), which then influences your judgement about it. So you must force yourself to look at your clever creation objectively. Is it hard to maintain? Is it more complicated than necessary? Almost by definition, the answer is "yes" - a simpler, not-clever solution probably exists. For the sake of future maintenance, DoTheSimplestThingThatCouldPossiblyWork.

The reason your darling must die is because you think its good. Quality isn't a matter of opinion. Prove that it is reliable and useful: TestEverythingThatCouldPossiblyBreak.

How do you prove a darling is reliable and useful after you kill it?

The act of killing is itself a proof by negation. If nobody misses it after its gone, then it wasn't useful. It probably didn't work either.

It's possible to kill darlings that are reliable and useful before anyone else knows about it, so killing isn't proof. People don't miss what they don't know about.

So what? YouArentGonnaNeedIt.

Misapplication of YAGNI. It is entirely possible to need a darling.

Key part of the definition: (...) stop and ask yourself (...). The "rule" exists to make your darlings get closer attention, not to tell you what to do with them...? -- FabioCecin

Then the rule has a misleading name. The name tells me to kill them, it doesn't tell me to pay closer attention to them. -- EricHodges

Perhaps the advice should be "Be suspicious of your darlings."

I tend to agree with BlueHat.

Don't delete whole programs just because you're proud of them. What the proverb means is, if you're "pretty satisfied" with the whole program and there's just one bit that you're "particularly proud" of, that one bit probably should be deleted.

Alternately, you could improve the rest of the program until everything is up to the level of the "particularly proud" code. ;)

The advice is to get rid of things that are excessively clever/elegant/cool/etc. If you are proud of it because it is just plain old good code, then leave it as is. If you are proud of it because it's just so damned cool you can't stand it, or if you expect people to be impressed with your ingenuity, then it probably needs to be made less cool.

When I saw this page, I immediately thought of people I've worked with arguing not to drop features, who cited the fact that they'd spent a lot of time working on those features as a reason not to drop them. I think that, too, is in the spirit of this guideline.

To me, KillYourDarlings is a deliberate overstatement - it's not meant to encourage you to blindly delete code you like, it's meant to encourage you to be reasonable and objective in reviewing your code, and perhaps to try that little bit harder to be extra objective about code you know you're intrinsically biased towards. I think this is a good general principle and should be applied in other walks of life, not just in programming.

A problem is that this advice is a HeuristicRule, but it's assumed to be right 100% of the time.

Oh I sure it can be made/interpreted to be right 100% of the time. Just extend its meaning suitably. The problem rather is that this is probably not what you want. See also TautologicalDefinitionFallacy.

The lyrics to KingCrimson?'s song "Indiscipline" [http://www.elephant-talk.com/releases/discipli.htm#lyrics4] provide a good test for "darlingness".

I love to kill my darlings.

But I won't do it until I have a more darling darling.

I like to come up with my more darling darlings myself, but I like it even better when someone else comes up with one, because that's less work for me, and it opens up new vistas in my mind...

A darling is not simply something good, or something that one is proud of. Darling implies great love, special favor, charm, amusement, etc.

So the advice to kill your darlings does apply 100% of the time in writing and in coding. If you feel emotional attachment or amusement with your code, you should work on it until it is mundane enough that you can evaluate it with a more detached viewpoint.

I find myself completely disagreeing with this advice. My darlings are the things which are my best code, not my worst. They're particularly clever typically because (for instance) they rely on an analogy which is less than obvious at first, but results in a significantly better design. A piece of code is particularly cool because of the terseness, efficiency, stability, level of abstraction and understandability of it, not because it dereferences a pointer to a pointer to a pointer (see ThreeStarProgrammer). Sure, the "***" in front of a variable looks cool, and I can appreciate it in a certain way - but I wouldn't say it's a darling; I'd call it a "clever hack", or "the thing actually works!".

Just because I can make a web server out of an XBox and think that's really really cool doesn't mean I'm using it in production. (But nor does it mean I definitely shouldn't - XBoxes are very cheap and abundant). What makes something a Darling for me, most of the time, is if it Just Works. What's wrong with that? -- PeterCrabtree?

I find myself completely agreeing with this advice. My darlings are the things which are my best code, not my worst. They're particularly clever typically because (for instance) they rely on an analogy which is less than obvious at first, but results in a significantly better design. A piece of code is particularly cool because of the terseness, efficiency, stability, level of abstraction and understandability of it, or perhaps because it dereferences a pointer to a pointer to a pointer (see ThreeStarProgrammer). Sure, the "***" in front of a variable looks cool, and I can appreciate it in a certain way - but I don't want to say it's a darling; I'd call it a "clever hack", or "the simplest thing that actually works!".

But, I rarely have the courage to do what I know to be good for my designs. -- JamesKjx?

(and, sorry PeterCrabtree? for being a little snide in my comment. But as I grow older and more curmudgeonly, I find this to be an excellent rule of life, but increasingly harder to take. After all, they are my darlings; I don't want to kill them! -- JamesKjx?)

I disagree with KillYourDarlings. I understand that it is a good principle to DistrustYourDarlings?, which inately implies that it should be tested but ... killing does not convey this message. My darlings are almost always neat functions that adhere to the OnceAndOnlyOnce principle. I am proud of them because I thought of them early not after replicating code 50 times then now having to go through and replace copy pasted code with a maintainable function. I am proud of them because they have to be general enough to fit in use cases I haven't even thought of because I am in the process of writing the code thinking that I'll eventually need this darling function in the future. -- AndrewRicketts

EncapsulateYourDarlings? It depends. If you are a programmer whose idea of a darling is a solution which is unclear and difficult to understand yet takes one less line of code, kill it. And get a job interpreting ancient texts.

If your darling is a better solution to a common problem, then either leave it there, or if it is difficult to understand for the reader, encapsulate it.

On second thought, encapsulate it anyway - you may later improve your darling. Somebody will. -- PeterLynch - who just cannot bring himself to delete anything

This is actually a possible strategy in the video game Bioshock. You are literally either killing children or sparing them at a minor material loss. A bit of a sick twist on the decision process. http://www.gamesanityblog.com/2007-08-28/i-cannot-harvest/

Origin

Attributed variously to SamuelJohnson, MarkTwain, DorothyParker?, GkChesterton, WilliamFaulkner, and GeorgeOrwell.

In his book "On Writing," Stephen King wrote: "kill your darlings, kill your darlings, even when it breaks your egocentric little scribbler's heart, kill your darlings."

In his lecture "On Style," Sir Arthur Quiller-Couch said, "Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it -- whole-heartedly -- and delete it before sending your manuscript to press. Murder your darlings."

See ThisAintTheRightPlaceToMuckAround