Kill your darlings

This is actually something I learned from my creative writing education. Whenever you have a sentence, you think is most beautiful, but doesn’t really fit into the whole text, than you will have to delete it. As a writer this was the hardest lesson to learn for me. I always, always stuck to my darlings and didn’t want to let them go. I wanted to create a happy place for them and what happens was, that I destroyed the rest of the text just to keep them. If you really love them so much, give them a place in your notebook and save them for later. But we all know what later means, yes?, later means never. That’s why it’s best to just kill them. “Killing” because it’s a brutal act for yourself and you might shed some tears. Maybe it helps you to remember, that it was you, who created that wonderful sentence or had that wonderful idea and then get over it.

Why do I talk about this? Because this week – it was a real hacking week with high code output from my part – I realized that this principle also applies to coding.

In our current sprint we had to develop a synchronization of documents. Doesn’t sound all too difficult, though. The web service interface to the other system wasn’t entirely clear and we had to wait for the access users, a query to gather all documents and stuff, so I decided we start with the writing to our database part. I designed a nice separation of concern architecture were we could inject the web service later when we had the saving part up and running as well as unit tested. That worked out pretty well and took more than half of our sprint. When we finally got access to the documents server in our last days of the sprint, we found out that opening a connection to the system was slow and the documents were big. We could have guessed that from the beginning, but at least I didn’t. When I tried to fit the service into our nice architecture, I got horrible performance and memory exceptions.

It was Tuesday afternoon, only 3 days in the sprint to go and I didn’t want to let go of the design and the work we had done so far, so I tried several different ways to still fit the service in. None of them really made me happy. The solutions I came up with killed the separation of concern anyways and weren’t much faster either. I discussed with my team member and told him, it might be best for him to go home, because I might have to redesign the whole thing. It was just then when I remembered the killing your darlings lesson I learned from writing. At 6pm I decided to throw the work of two team members away, as well as all the unit tests and code a whole new approach.

Please don’t misunderstand me, I delete, undo and throw away code all the time. I actually have no big problem with that. My problem was that I had to redesign the whole architecture of the code and throw away the unit tests! Ok, actually I just wanted to keep the unit tests! If I just could have kept the whole interfaces and redesign the black box inside, I could have nicely use my unit tests to see that still all is up and running as expected. And the unit tests took so much time to write! And I did such a nice TDD approach with them. It was really hard to let them go, but they are history now. And with history I don’t mean that there are no unit tests now, I just had to rewrite them too.

I rewrote the code in one day and made it work. Performance is good now and the goal is reached.

The end of the story? If you ever cry about throwing away your code or unit tests, you might just remember me and kill your darlings right away. Maybe it helps you to remember, that it was you, who created that wonderful code or architecture and then get over it.