Every programmer has faced this situation: you have to throw away code that you previously sweated over. For whatever reason, you no longer need it, so you have to remove it from your program.
I enjoy this because it feels like I’m cleaning up my application. I like to pretend that the old code I’m getting rid of is low quality crap that I’d never write these days.
But I wouldn’t say it’s easy. It’s like trying to part with all those old mementos in your closet that you kept because they used to mean something to you. It’s nice to have a clean closet, but as you’re throwing stuff out, you can’t help but remember how important it used to be. In the case of software, you remember how much time you spent writing the code that you’re now putting out to pasture.
I faced this situation earlier this week. A customer reported that FeedDemon was seriously spiking his CPU when updating feeds, and when I tracked the problem down, it turned out that the spinning animation shown in the subscription tree was the culprit.
So in the latest FeedDemon 2.6.1 beta, I threw the animation code away. And it was a lot of code – you’d think adding simple animation to a treeview would be no big deal, but getting it to look decent required a ton of little hacks that added up to some significant coding time. I loved getting rid of all those little hacks, but I sure wish I could get back the time I spent writing them.
As an aside, people often think that developers spend most of their time on big, shiny new features, but the reality is that we spend far more time on tiny details like getting a stupid little animation to look smooth. When you see software which shows great attention to detail, keep in mind that some poor sleep-deprived geek spent weeks refining those details, even though they’d rather be playing Rock Band.
Amen. You can’t get too attached to one’s own code. Sometimes you love something and it works, but it could be done in a more efficient manner — its hard to rip the old code out in favor of better code. And even tossing commented out methods in case they become needed again is tough. But cleanup of code and attention to details really makes a difference. Good post.
While it can be tough to get rid of code that you spent a good deal of time on for me it’s an even better feeling to make my code more readable, more user-friendly, and more performant. Plus if you ever have the secret desire to look at the removed code again you can always look at a file’s history in your version control system. You are using version control aren’t you? ;-)
Great post. I often tell people that my next favorite thing after writing code is deleting it. Of course, not arbitrarily ;)
Cheers,
Robert
I throw away code all the time too — but of course I keep a copy of it. It’s very cool to have the same problem again after some time and have older code ready for it — and often, that older code may seem hairy and messy but many of the parts are there for some reason, often some good reason.
Knowing when to cut, when to start from scratch and when to readapt an uninspiring codebase is one of the tricks of the trade, methinks. (One has, at this point, to link to Joel Spolsky’s “Things You Should Never Do, Part 1” which is only tangentially related, as it talks of rewrites rather than cuts, but then: http://www.joelonsoftware.com/articles/fog0000000069.html )
Throwing away codes can really be hard. Sometimes, I get so attached to some classes/components that I practically give them names; dudes, blokes, etc!
So deleting them is like killing them. The worst thing is when you dump your own code for another patch from someone’s which is more efficient. It is like adultery…
I love cleaning code too. But sometimes I can’t help feeling jealous when some new technique makes my hard work obsolete. All of the sudden new generations of geeks are coding the same thing that took me 3 months in one line. Than I feel so old :)
Cheers Nick, can’t wait to see new FD. :)
You said it very well, Nick, especially the part about the “tiny details”.
Every 1 feature includes 30 details. The feature is usually easy to add. 25 of the details are easy to add, but take time. The 5 last ones are a pain.
Plus, then you have to revise your documentation. If the feature changes the main screen, you may have 100 screen shots to update.
Then several months later, a bug shows up. And it’s in one of the details. After taking hours to track it down, it either takes seconds or hours to repair. Aaaargghhh!
Nick, 2.6.1 betas, really feel faster while updating all chanels, so nice job.
Glad to see FD is getting better by polishing pending issues on it, so let me write some suggestions to your development:
– Portable version: Distributed as an standard ZIP file, and avoiding to write on the registry.
– Custom installer: Allowing user to choose what components to install (ie FeedStation, …).
– Office 2007 look and feel: I do not know if a ribbon bar would be needed, but at least upgrading current themes. I am sure the VCL components used, could be upgraded to support Office 2007 themes.