productivity apps

Do you really wonder, how much time you spend each day browsing Wikipedia ? -or- Lolcats ? Do you want to control the time you spend at Orkut or Facebook ? Yes, you can. There is a Firefox plugin for you at 8AWeek. It adds a toolbar in firefox, with which you can configure which sites you want to restrict and the time you want to spend with restricted sites. And at the end of the day, it produces a graph something like this.

The ones in red color are my restricted sites. It also gives grades based on the how well you group your browsing, % Restricted, and Overtime. My grade report looks like this.

Nah, I am not really proud of that, but I get a feel about what kind of online grazing I do. Now, if you want to expand such an analysis to your desktop – Yes, there is an application for that too. Recuetime is desktop application, that keeps track of the time you spend on each desktop application. Unlike 8AWeek, you have to signup on their website. It gathers information and sends to rescuetime.com servers, where you can analyze the your desktop habit stats. This is how my dashboard looks like.

Of course, there are a lot of options in RescueTime – such as rating your tags, setting up productivity goals, which I haven’t explored. Still, I find the application very useful.

I can’t say I am productive using these applications, but I can say they have changed the way I work. Now, I no longer wonder, where did all the time go. The answer is right there on these pretty bar charts.

why can’t software be like an aircraft engine ?

When dealing with software professionals, the users tend to asks questions like why the making of software doesn’t work, exactly like their actual job. And when you make a software for the engineers who design, develop and test Aircraft engines, they seriously ask questions like why this software can’t be like an aircraft engine.

I get really excited about such comparisons. When it comes to software, I always hold the opinion that there is no comparison that fits. I wish the poet Pablo Neruda had written some poems about making software. Then, at least, we would not have this shortage of good metaphors.

I wrote a blog entry sometime ago about what I do for a living. I can say it again – RSA wouldn’t mind it actually – I work on a team of customizing an Engineering software for an Aircraft Engine manufacturer. We work on a monthly build cycle, that works fairly successful in fixing bugs and introducing a new feature every month. In plain words, we put in a new version of the software every month for our users – with a new major functionality and a few bug fixes.

There are no dedicated testers here. (Yeah, I know. Just give it a break. It’s just a customization project). Its the actual users who test it in a simulated test environment, before we push the software to the real time, live wire production environment(Again, with the shortage of metaphors in Software Engineering, we use buzzwords!!!) . In the previous build, it happened that the testing for the major functionality was complete, but the bug fixes – We couldn’t get enough users to test them!!! Obviously, we can’t push the software to Production, until we are sure we aren’t breaking anything with our “fixes”. So we had to delay the build a week. When we told that to our clients, one of them had this to say….

You are saying that you can’t push the software to prod until the bug fixes are tested ? Its like saying – Even though the nozzle assembly of the engine has been tested for every other performance metric, and just because a small component such as a bracket is not available, I can’t ship the engine. Can’t you just pull out the bracket ?

When all of our customization is built and bundled into a single shared library (All of them are in a single binary file), it is impossible to pull the fixes from the dll file. Sometimes, I do wish I have some supernatural power by which I can rip apart the bytes of that binary file, and pull out the ugly “brackets”, I wish I had not made. (The main reason would be – save some embarrassment.)

Unfortunately in Software Engineering, we are still trying to figure out how to do things better. And all I can say is that making parts of working software into components hasn’t reached the level of granularity of building an engine – to its bolts and nuts.

It is not impossible. (Pardon the double negatives. I need to be explicitly equivocal here.) You just need a highly flexible version control system, probably use a scripting language instead of a compiled language (a framework like Ruby on Rails ???), then a perfect system of tagging, naming, arranging builds, then of course, a reliable system of automated testing, and then finally a highly granular configuration system – seamlessly integrated with the rest of them.

If we can have all that systems, then probably we can “pull out” stuff that is not required. In short, it is just not like pulling nuts and bolts or even a bracket out of an aircraft engine assembly. (Or it could very well be just that the comparison of bug fixes in a software to a bracket in a engine could be wrong. I told you – We badly need Neruda)