A couple years ago, FeedDemon started displaying favicons – you know, those little 16×16 icons that web sites use to brand themselves. It was a popular addition, because it’s much easier to tell your feeds apart when they don’t all use the same generic feed icon.
It seemed like such a simple feature at the time. Just check the root folder of the feed’s homepage for the favicon, download it if it exists, then display it in FeedDemon. No big deal, right?
The first problem was web sites that lied when I requested the favicon. They’d use the wrong MIME type, so I couldn’t rely on that to determine if I was actually getting an image. And all too often they’d indicate that the favicon existed by responding with an HTTP 200, but instead of returning a favicon they’d give me an HTML document that contained a 404 error message. So that meant writing code to handle that situation.
The next problem was the sheer number of favicons that used the ICO file extension but turned out to be bitmaps. Or GIFs. Or PNGs. Or JPEGs. Or some undiscoverable format. Which meant writing code to detect the true image format, and more code to convert them to Windows icons (something I didn’t get right until last week’s FeedDemon 2.8 Beta 3).
Then came the fact that not all versions of the Windows API play nice with truecolor icons, and the version of the development tool I’m using doesn’t handle them well, either. More code to handle that situation and fail gracefully.
And, of course, I had to reflect changes to a site’s favicon, as well as detect when a site that didn’t previously have a favicon suddenly got one. And this had to be done in a way that was bandwidth-friendly, both to the client and the server (not as simple as it sounds given that many sites don’t correctly return an HTTP 304 when a file hasn’t been modified).
Oh, and I also had to scale the 48×48 and 64×64 favicons that some web sites inexplicably use. Not to mention the fact that ill-mannered anti-virus software would sometimes lock the downloaded favicon file right after I created it, resulting in a “file in use” error which I had to capture and work around.
Etcetera, etcetera, etcetera.
The end result is that it took thousands of lines of code just to display favicons. And that’s often the case with features that seem simple at first glance. It’s not until you dive into the code and find all the weird problems and bugs that you realize your little feature is actually a big PITA.
So what’s the point of this seemingly pointless blog post? Really, it’s just to explain my response to customers who ask when I’ll be adding a specific feature:
“I’m planning to add that to the next version, but I can’t promise anything until I’ve actually started coding it.”
I know that response sounds glib to those who hear it, but it’s really me being honest. If I haven’t tackled a feature in code yet, then there’s no way I can reliably estimate how long it will take to complete it.
Related post: Start Coding Like a Cowboy