Stories about Software


Throw Out Your Code

Weird as it is, here’s human nature at work. Let’s say that I have a cheeseburger and you’re hungry. I tell you that I’ll sell you the cheeseburger for $10. You say, “pff, no way — too expensive.” Oh well, I eat the cheeseburger and call it a day. But I’ve learned my lesson. The next day at lunch, to execute my master cheeseburger selling plan, I slide the cheeseburger over in front of you and tell you that you can have it: “you can have this cheeseburger…” Just as you’re about to take a bite, however, I cruelly say “…for ten dollars!” You grumble, get out your wallet and hand me a ten dollar bill.

This is called “The Endowment Effect,” and it’s a human cognitive bias that causes us to value what we have disproportionately. I blogged about it here previously in the context of why we think that our code is so good we should SPAM it all over the place with control-V. But even if you don’t do that (and, really, please don’t do that), you still probably get overly attached to your code. I do. After all, we, as humans, have a hard time defying our own natural instincts.

I’m certainly no anthropologist, but I suspect that our ancestry as nervous, opportunistic scavengers on the African Serengeti has everything to do with this. Going and snatching a morsel that a hungry lion is eyeing is a pretty bad idea. But if you already have the morsel, what the hey, you might as well take it with you as you run away. But, however we’re wired, we’re capable of learning and conditioning our own responses. After all, we don’t go bolting away from the deli counter after the guy there hands us our two pounds of salmon. We’ve learned that this is a consequence-free transaction.

It’s time to teach yourself that lesson as it relates to your code. It’s not so much that deleting functional code is consequence free (it isn’t). But deleting it isn’t nearly as big of a deal as you probably think it is. When it comes to code that you’ve spent two weeks writing, I’m pretty willing to bet that if you trashed it all and started from scratch (no peeking at source control history), you could rewrite it all in about two days. If that sounds crazy, ask yourself whether the majority of the time you spend programming is spent furiously typing as if you were taking a words-per-minute test or if most of it is spent drawing things on scratch-paper, squinting at your screen, pushing code around unit tests, muttering to yourself, and tapping a pen on your desk. I’m betting it’s the latter, and, when you rewrite, it’s activities from the latter that you don’t do nearly as much. You’ve already blazed a trail for yourself and now you’re just breezing through for a second trip.

Write some code and throw it out. Do a code kata with the stipulation that the code is deleted, never to be recovered. Then try it again the next day and the day after that. Or create a copy of your production code at work, engage in some massive, high-risk, high-wire-act refactoring, and then just delete it. With either of these things, I promise you that you’ll learn a lot about efficient coding and your code base, respectively. But you’ll also learn a subtle lesson: the value you’re creating as you code can be found more in the knowledge and experience you’re acquiring as you do it than the bits sitting in source control.

Practice throwing out your code so that you stop neurotically overvaluing it. Practice throwing out your code because it’ll probably happen by accident at some point anyway. Practice throwing out your code because your first crack at things usually kind of sucks. And practice throwing out your code because end users and the world are cruel, and not everything that you write is going to make it gift-wrapped into production. The more you learn to let go, the happier and more productive you’re going to be as a programmer.

  • Eric

    I just had to respond with this video of 3 Maasai men doing exactly that which you call a bad idea! 🙂 http://bit.ly/13ScgYI

    • lol… that’s pretty intense. I think I’ll stick to the deli for my wildebeest, personally.

  • Great article. I especially liked the last two paragraphs, which have “teachings” that can be applied to anything in life for which there can be some type of attachment.

    It’s fair to say that your article “hides” tremendously helpful practices that can “upgrade” someone’s skills but also his character, in many levels and if someone would nitpick it, he probably lost the general point.

    • Thanks — glad you liked! I deliberately made this a rather oversimplified post simply for the effect. I just kind of wanted to say “go ahead, throw out something you did” to encourage people to do it and realize that the world doesn’t end.

  • Geoff Mazeroff

    I hadn’t heard of the endowment effect before. Would you also consider that this is related to “loss aversion” as well? We’ve invested so much in our code, why would be abandon it?

    • I think the concepts are closely related. In my (limited) understanding, the Endowment Effect is that people value something more once they have/own it and Loss Aversion is the idea that people fear loss more than they value gain (e.g. someone will be made unhappier by a loss of 5K a year in salary than be made happier by a 5K per year gain).

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1403()

  • edA-qa mort-ora-y

    The attitude should be all encompassing as well. Automatically throw away any unused code, and any commented bits of code. Chances are it will never be used again, and the next time it’d be written better again.

    I tend to trust my source control. I believe I could go back if I wanted to. But honestly I almost never go back to an older version looking for code.

    • I completely agree with that. Every time I see commented out code, I delete it without even looking at what it does. Poof, gone. That one in particular I just don’t get — I mean, everyone’s been using source control for a while now, right?

  • Porter

    Good idea. It would be pretty neat if somebody could make a scientific study about this, pin down what effect it has on different kinds of programmers.

    • I’d be interested to see a study like that as well. One of the things I loved about grad school was being exposed to a lot of white papers where studies like this were conducted. I remember some on things like code readability and method size. In another life, I think it would have been fun to go the full-fledged academic route of PhD –> Professor.

  • This approach can be applied to many “things”, like for example drawing skills or photography.