When I worked with Zak Tamsen, one of his favorite (software development) sayings was: Kill Your Darlings. The idea was simple, don't get too attached to code.
I'm not sure why so many developers become so attached to code they've written. Perhaps developers have the same attachment to code that artists have to their paintings or music. Or, perhaps they view their legacy code as job security. Whatever the reason, developers seem to have some illogical desire to extend the life of code they've produced.
Of course, the desire to make legacy code live-on isn't universal. I tend to live in the opposite world, where I can't delete code fast enough. As much as I'd like to believe that people who share my views are evolved in some way, I know it isn't true. At least in my case, I like to delete code because I have ADD. Plain and simple.
Someone recently asked me how I deal with developers who are over-attached to their code. I've only found one successful way: create a finished solution that is simpler, and then share it with the original developer. Unfortunately, this path doesn't exactly promote collaboration, so it can definitely lead to other problems.
George Malamidis taught me something about code attachment a few years ago: You always gain by allowing someone to show you an alternative solution. If someone wants to solve a problem in a different way, there are several gains to be had. If their way is inferior, you have an opportunity to mentor a team-mate. If their way is equally elegant, you've gained another solution, or point of view that may be superior in the future. If their way is superior you learn something new and the codebase improves. In exchange for these gains you only need to give up time. Time is valuable, but it's also well spent on improving the ability of a team-mate or your personal ability.
Michael Feathers has also written on this topic, specifically focusing on frameworks. In Stunting a Framework, Michael discusses creating small focused frameworks and then letting them go. I think Michael really nailed it with that entry, it's definitely worth a quick read.
I think killing your darlings extends beyond codebases and frameworks to languages themselves. At SpeakerConf 2009, I floated the idea that we should more actively seek to kill languages. Perhaps, after 3 versions of a language, it's time for that language to be retired. Imagine what we could create if the resources dedicated to Java were instead focused on creating a successor to Java. Think of all the time that would be saved if backwards compatibility became a non-issue.
I can imagine the horror of developers who have written and used frameworks for Java. What would we do without all those frameworks? The reality is, we'd port those frameworks and improve them. There's thousands of developers who are dying to port an existing framework to a new language. And, frameworks should be stunted anyway, if you agree with Michael (which I do).
We are already evolving. New languages are appearing all around us. Frameworks are born and killed at a rapid pace. However, the attachment to code, frameworks, and languages only slows our maturing process. Be aware of, and support progress. Kill your darlings.
Awesome. I recently did a code review on a CMS built from scratch by inexperienced rails developers. A decision needed to be made on whether to keep the existing codebase or just flush it. I said the app lacked integrity and you just flush it and start over. I told them to take a look at Radiant CMS and pay attention to how they solved the same problems but a lot more elegantly and then move forward with the things you learned still fresh in your head.
ReplyDeleteThey looked at me like I was space alien. This was a year's worth of effort after all. Just flush it?
Yeah, just flush it, you didn't know what you were doing at first, you'll build it faster and better now.
You can get attached to your girlfriend but don't get attached to your code.
The framework I personally "killed" was NAnt, the .NET version of the Ant build framework. I switched to Python for creating build scripts since using XML in this manner seemed antiquated.
ReplyDeleteIt surprises me how attached programmers are still to Ant and not considering new alternatives. Even back in 2003(!), the creator of Ant lamented how it has become too much like a scripting language when something like Jython would have been preferable to handle control flow logic.
Yes. Programmers do need to "kill their darlings" and continue to seek out new and better ways to do things. Like you said, this includes languages themselves once they have run their course and something better exists to supplant it. Just let it go.
I suspect if you solve this, you will have solved the problem of the sunk cost fallacy.
ReplyDeleteGreat article, Jay.
ReplyDeleteI've recently gone through a cleansing purge of features (and therefore code), so that an application could be moved forwards. It's very liberating. Less code means less to maintain and understand.
You might have poured blood, sweat and tears into it, but if it ultimately isn't useful then it should just be treated as a sunk-cost and happily jettisoned.
You can get attached to your girlfriend but don't get attached to your code.
ReplyDeleteI couldn't agree more ;-) Somehow, may developers tend to think that their code equates to the kind of developer they are. This kind of attitude really bogs down individuals, making them closed to ideas and room for improvement.
"If their way is inferior, you have an opportunity to mentor a team-mate."
ReplyDeleteYeah, there's nothing they love more than to write replacement code only for me tell them "mine is better, let me teach you how to do it properly". The language used makes no difference other than the time it takes for that message to come across. How reasonable the argument is doesn't make a difference. How good your intentions are doesn't make a difference. People just don't like an appraisal ending in a lesson, they see it as failure.
(Apply the disclaimer 'in my experience' to all of the above.)
I have long held a similar opinion but mainly contrary to the opinion you give about musicians and artists; it's from working with them (as a musician) that I learnt to not be precious about your output (or as Freud put it being anally retentive).
ReplyDeleteI actually thing that developers need to take a leaf out of artists and musicians books. Both, when at the top of their game, learn to stop being precious about their ideas and are throw things out when they don't work: it's an essential part of improvement. Some artists continuosly rework their ideas even over their lifetimes: how can Leonard Cohen have hundreds of different versions of Hallelujah, why do you think Paul Weller won't reform The Jam, home many times did Van Gough reuse the same canvases?
Here's a few wise words that I believe are very relevant to development:
"There is no great writing, only great rewriting." - Justice Brandeis
"Books aren't written - they're rewritten. Including your own. It is one of the hardest things to accept, especially after the seventh rewrite hasn't quite done it." - Michael Crichton
This reminds me of an interview question I had.
ReplyDelete"What piece of code have you written that you're most proud of?"
I guess I just don't feel that way about my code as I struggled to come up with an answer.
I eventually mentioned the code for a website I'd recently created that was gaining some traction with users.
I wasn't particularly proud of any of the code as such, more that it was out there and being used.
Not sure they quite got my answer but I got the job anyway!