Earlier this year I wrote about the joy of throwing away your code. It’s true – as a rule, programmers generally love getting rid of old code. But I discovered a corollary to that rule: it sucks to throw away code that you just wrote.
I know because I had to throw away a ton of code I wrote last week.
You know that upcoming FeedDemon feature I wrote about in my last post, the one which shows where a shortened URL will take you? Well, in my first design, it didn’t display a balloon tip with the long URL. Instead, when you clicked a short URL, it took you to a separate preview page that looked like this (click to enlarge):
I spent a few days coding this, but when I sat back and looked at it, I wasn’t wild about how you had to click a short URL to know where it would take you – it seemed like an unnecessary step. I decided it would be better to show the long URL as you hovered over a short URL, which meant getting rid of the preview page and adding the balloon tips.
I almost didn’t make the change since the idea of throwing away hundreds of lines of freshly-painted code was too painful, but in the end I convinced myself that making the feature more usable was more important than saving my fragile programmer ego.
Perhaps that’s a lesson for other programmers, too? I’m sure there are countless features in other applications that could be greatly improved, but most developers can’t bear the idea of throwing out recent code (besides, we like to show off by adding new features, not rewriting existing ones). But you know what? I’d pay to upgrade several applications I use if the new versions simplified existing features without adding any new ones.
Actually, I think throwing away new code is as much fun as throwing away old code. Sure. At the moment, it feels like you’ve just wasted a lot of time and effort, but in retrospect, you will always find that the new solution works much better and that because you dared to take that step, now you have a more maintainable and better working solution.
Once I started throwing away good, but not perfect code, I may have gotten slower in producing presentable features, but the overall code quality has improved so much that a) finding the (much fewer) bugs left is very easy and the are very easily fixed and b) extending the code for new requirements is much easier when it’s cleanly built.
Yes. At the moment, throwing away a lot of stuff may hurt, but in retrospect, I guess it’s always worth the hassle.
If you write non-perfect code now, it feels quirky now and it’ll hurt a lot later when the bugs/usability problems appear.
OK I don’t know whether I should include this or not as if you will follow my advice you will have to throw away your code completely (or most part of it).
I think how about if you use Firefox as the engine for feeddemon instead of the Internet Explorer.
What it will do is get users with better browsing and will also have the ability to use the Firefox plugins and their customized browsing settings.
It would be great panic for you I know but then endless possibilities will open.
@Ankit: I’d love to embed Firefox/Mozilla in FeedDemon – see http://nick.typepad.com/blog/2008/03/can-mozilla-be.html
@Ankit – Search the FeedDemon Forums for firefox. The bottom line is that it’s not physically possible – and that’s due the limitations of Firefox – they do not make an embeddable version suitable for use in an application like IE does. There used to be an embeddable version of Mozilla that could be used, but it is so old that Nick had to remove support for it due to several severe security issues.
In addition, the “endless possibilities” also translate to “endless headaches” when dealing with the support (and bug-squishing) side of the application. Think about it – this would essentially mean that Nick would have to support Firefox as well as FeedDemon.
At least with Delphi, the amount of discarded code is much less than vb, c# and their ilk. And, as Mark Miller’s challenges demonstrated, the time it took to develop the discarded code will be significantly less. For me this is very helpful as most of my code gets discarded anyway.
I love to throw away code if I’ve found an optimization, but hate it if I’ve gone down the wrong path or I discovered I was re-inventing something someone else did… it feels like throwing away time, even if the end result would have been better. Just have to shrug and move on.
New code has gotta go if ultimately it doesn’t enhance (whatever that may mean) the user-experience from the previous code. I’ll add stuff and then rip it out again a week later if it just plain gets in the way too quickly. Shrug and move on is right.
Have you looked into embedding WebKit? It might be easier, since NetNewswire already does it, and Safari has an automatic update mechanism and shared libraries.
@Brad: I did briefly look into embedding WebKit, but I didn’t get anywhere with it. And I’m not sure what that would really gain me, either, since the vast majority of customers are either running IE or Firefox.
You know a preview page wouldn’t irritate me that much, i do get a bit irritated by balloon tips, i always shake the mouse to get rid of them. Maybe you could put something in options, keep the code (:
As an embedded programmer I quickly learned the first was nearly always thrown away unless I was was working on something I already knew how to do.
With the API’s we have today a lot less need to in the trash. But I expect it not much different for the small part of the code that does the new stuff.
Evey second we spend on project after we start working on the solution we are more and more infested in the work we have done. It becomes harder and harder to admit we made a mistake. So really understand the problem before you start to write code it at all possible. I worked a good deal in ares that wasn’t always possible and quickly learned not to become attached to my code or get my ego entwined with it.
There sure is a lot crappy code written by people that don’t understand what their doing but just meet the specifications. On 3 occasions I have had to redo jobs that better programmers than me failed on because they tried to do what the specifications called for and the specs were wrong. One took two years of research to find out what was wrong with the specs. So a lot of time and money can be wasted that way.
Gordon