Tuesday, March 31, 2009

Kill Your Darlings

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.
Post a Comment