Switching to Tiny Tiny RSS

With the imminent demise of Google Reader, and FeedDemon consequently being end-of-lifed, my next task was clear: find a new RSS aggregator. This was not something I was looking forward to. However, as things turned out, I actually got to solve the problem in more or less the way I'd wanted to for years.

The thing is, I never really liked Google Reader. The only reason I started using it was because I liked FeedDemon and FeedDemon used Google Reader as it's back-end sync platform. (And if you've ever tried to use a desktop aggregator across multiple systems, you know that not being able to sync your read items across devices is just painful.) But I seldom used the Reader web app - I didn't think it was especially well done and I always regarded the "social" features as nothing but a waste of screen space. Granted, the "accessible anywhere" aspect of it was nice on occasion, but my overall impression was that the only reason it was so popular was because it was produced by Google.

The other issue with Reader is that I don't trust Google or hosted web services in general. Paranoia? Perhaps. But they remind me of the saying that "If you're not paying for the product, then you are the product." And while I know a lot of people aren't bothered by that, I think that Google knows far too much about me without handing them more information on a silver platter. Furthermore, you can't rely upon such services to always be available. Sure, Google is huge and has ridiculous amounts of money, but even the richest company has finite resources. And if a product isn't generating enough revenue, then the producer will eventually kill it, as evidenced by the case of reader.

tt-rss-thumb.png
What I'd really wanted to do for some time was to host my own RSS syncing service. Of course, there's not standard API for RSS syncing, so my favorite desktop clients wouldn't work. But with FeedDemon going away as well, and having no desktop replacement lined up, I no longer had to worry about that. So I decided to take a chance on a self-hosted web app and gave Tiny Tiny RSS a try. I was very pleasantly surprised.

The installation for TT-RSS is pretty simple. I use a shared hosting account, and though the documentation says that isn't supported, it actually works just fine. The install process for my host consisted of:

  1. Copy the files to my host.
  2. Create the database using my host's tool.
  3. Import the database schema using using PHPMyAdmin.
  4. Edit the config.php file to set the database connection information and a couple of other settings.
  5. Use my host's tool to create a cron job to run the feed update script.
  6. Log in to the administrator account and change the default password.
  7. Create a new account for myself.
  8. Import the OPML file that I exported from FeedDemon.

That's it. Note that half of those steps were in the TT-RSS UI. So the installation was pretty much dead-simple.

In the past, I wasn't a fan of web-based RSS readers. However, I have to say that Tiny Tiny RSS actually has a very nice UI. It's a traditional three-pane layout, much as you would find in a desktop app. It's all AJAX driven and works very much like a desktop client. It even has a rich set of keyboard shortcuts and contextual right-click menus.

mobile-thumb.png
As an added bonus, there's also a pretty nice mobile site. While the latest release (1.7.5) actually removed the built-in mobile clientweb site, there's a very nice third-party JavaScript client available. It uses the same API as the mobile clients, so the installation pretty much consists of enabling the API, copying the files to your host, and editing two settings in the config file to tell it the path to itself and to TT-RSS.

But who cares about the mobile site anyway? There are native Android clients! The official client is available as trial-ware in the Google Play store. And while it's good, I use a fork of it which is available for free through F-Droid. In addition to being free (as in both beer and speech), it has a few extra features which are nice. And while I may be a bit cheap, my main motivation to use the fork was not the price, but rather the fact that the official client isn't in the Amazon app store and I don't want to root my Kindle Fire HD. This was a big deal for me as I've found that lately my RSS-reading habits have changed - rather than using a desktop client, I've been spending most of my RSS reading time using the Google Reader app on my Kindle. The TT-RSS app isn't quite as good as the reader app, but it's still veyr good and more than adequate for my needs.

Overall, I'd definitely recommend Tiny Tiny RSS to anyone in need of an RSS reader. The main selling point for me was the self-hosted nature of it, but it's a very strong contender in any evaluation simply on its own merits. In my opinion, it's better than Google Reader and is competetive with NewsBlur, which I also looked at.

Estimation SWAG

Last summer I learned a new acronym, courtesy of Chinmay. He asked for a developer to put some estimates on the outstanding technical tasks needed to make a demo production ready. So I fabricated a few numbers, slapped them on the wiki page, and dropped a note in the project chat room saying that I'd put up some grossly inaccurate estimates. Chinmay replied by thanking me for the SWAG - Sophisticated, Wild-Ass Guess.

The reason I like this acronym so much is that it pretty much sums up all the software estimates I've ever seen. I mean, it's not like there's no methodology to it - you look at the task, break it down into pieces, and apply some heuristic to attach a number of hours to each piece. But really, at the end of the day, it's all just guess work. The "heuristic" usually just comes down to a gut feeling of how long something ought to take based on your knowledge of the system. In other words, a guess.

And it's not like there aren't more organized ways of doing this. We could use COCOMO models to come up with our estimates, for example. The problem is, approaches like that require you to have actual data to use as a basis for comparison, and most teams don't have that. Or they do have it, but the data is useless - corrupt, fabricated, poorly defined, etc.

The reason it's hard to get good data on developer productivity is obvious to anyone who has ever worked in a pathological development shop - because it can be dangerous. In a good organization, such data would be used to estimate costs and schedule and to help make better decisions about what projects to do and where to allocate resources. In a pathological organization...not so much.

In a pathological shop, measurement is used against you. If the measurement is number of hours needed to complete a task, then you'll be judged to be incompetent or slacking off if a "simple" task takes you "too long" to complete - where what counts as "simple" and "too long" are determined by a non-technical manager who really has no idea what you actually do. Or perhaps you'll be required to account for all eight hours of your day, down to five-minute increments. Because heaven forbid you should "cheat" the company by taking a bathroom break.

When I think of pathological examples of measurement, I always think about my last job with an online advertising startup. At one staff meeting, our VP of Engineering announced that he new expectation was that engineering would deliver on its estimates with 90% accuracy based on 80% definition from the product manager. So we were required to be 90% sure how long a task was going to take, even though we were only 80% sure exactly what it was we were building. And based on previous experience with the product manager, calling the specs he gave us "80% definition" was really generous - I'd say it was more like 50%.

In that case, the productivity measurement was being used as a tool to force the VP of Engineering out of the company (and it worked - he put in his notice the next week), but the principle applies to anyone - if a measurement can be used against you - even if that use is unfair and out of context - assume it will be used against you. That's a very sad reaction to have, but it's natural if your experience is primarily with unhealthy shops. And while I don't endorese such a paranoid attitude, having been in such a shop more than once in the past I can certainly understand it.

One of these day, I'd really like to work in a shop where performace metrics were used as a real tool in project planning. Even in healthy shops, this sort of thing seems to be uncommon. That seems to be something of a comment on the state of "software engineering" as a discipline. The differentiator between quality and pathological shops seems to be the absence of bad practices as opposed to the precense of good ones. Even in good shops, building software seems to be less engineering and more art or black magic.

Personally, I'm not convinced that that is a necessary or desireable state of affairs. I'd just like some first-hand evidence to support that suspicion.