December is running out of days fast and I still haven’t written my annual review of things I planned or did, intentionally or otherwise. I’ve been thinking about it for a while, but couldn’t find words to express myself. Finally I gave up. I don’t think I’ll succeed now, but I doubt more time would help.

For me this year has been absolutely wonderful. Coming to Zemanta meant I could work on interesting problems to improve a tool I use myself while collaborating with people I like and respect. I traveled to more conferences than ever before and generally learned a lot. I’m proud of my team’s achievements and of what we did as a company. It is indeed a privilege to have a gig like this.

I’ve also started a private project with a friend, which is coming along nicely. It shouldn’t be too long before we can show it to, well, everyone interested. Hopefully that means to many.

In all, 2008 was great for me and I don’t think 2009 will be worse.

Yet of late I’ve been feeling increasingly gloomy. This has remarkably little to do with economic crisis, influence of which we can already feel even if it’s yet to hit with full force. I won’t be traveling as much next year, but I planned to do less of it even before I knew there might be economic reasons to do so.

I’ve been worrying about the state of our planet for years. Things weren’t getting better as quickly as I thought they should. In fact, they aren’t getting better at all, but I hoped we would turn and do what needs to be done when given last chance.

There are many things that are deeply wrong in this world. Slavery is more widespread than probably ever. We know we should reduce the amount of CO ₂ in atmosphere, yet we do opposite . Fisheries around world are rapidly collapsing taking whole ecosystems with them. Glaciers are receding with probably disastrous effect on water supplies for millions of people. Rising world population will continue to negate any progress we may have. I could go on , but this list is depressing enough.

After all it’s not the scale or number of challenges that is dispiriting . It’s our inability to act decisively. We prefer compromises that set targets too low and then fail to meet them. There are 6.5 billion of us, but we are still unable to face real probability that this may be too many. I sometimes wonder how lives looked like in last days of civilizations long gone, most of them disappearing precisely because they taxed their environment too much. I hope I’m wrong and never find out.

I wished to end this post on a positive note, but I’m clearly failing. I do sincerely wish everyone happy holidays and the best of luck in next year. I’m afraid we’ll need it.

I use Gmail mainly for reading mailing lists. I’m old-fashioned and prefer to have my email where I can control it, but otherwise I can’t fault Gmail much. I wish search worked better and until today I wished to have a folder with unread messages.

Well, there is a way around second problem for those, who can turn on Gmail lab features (which hosted domains can’t). Go to the Lab tab in settings and turn on Quicklinks. After that return to Inbox, type is:unread in search box and confirm.

When you get results view, just press Add Quick Link in Quick Links widget, pick a name you like and voila, you have a view which lists unread messages. It’s not perfect though. It won’t show you how many messages are unread and you can’t subscribe to it through IMAP .

The other thing that is not perfect is Google Docs , which I quite like. I did encounter a problem with it that is not important right now, but I imagine it might be in not too distant future.

How do you move documents between accounts?

What you can do is share the document with account you want it moved to and then delete it. If you are owner of this document, you will get a pop-up with a choice to transfer ownership before deletion. Again, it seems I can’t transfer it to a hosted domain account, so this trick is not only not obvious, but also doesn’t work all the time.

If there are better ways to accomplish above two things, then I would love to hear them.

Update : It seems part of my post became untrue even faster than usual.

I was reading Paul Graham today, who among other things touched on a subject that has been on my mind lately. Software shipping.

At Zemanta, we usually don’t ship daily although when needed we do. We try to do a release of new features and bug fixes every 2-3 weeks and on the whole we are succeeding. Still, this is not as often as many startups profess to do and it’s certainly not as often as most of us would like. Even though I probably bear the majority of “blame” for this, I too wish we shipped more often.

So why don’t we?

There are many factors that define how quickly can something be shipped and even though I don’t think I have an exhaustive list, I find following most important (listed in no particular order):

• code base
• shipping changes
• team
• tolerance of failure
• time

Code base

Simply put, better code is easier to change and evolve with new features without introducing new bugs.

Speed of development rarely results in pristine code, so we need to clean things up every now and then, which creates a need to regularly evaluate the quality of our code base and its impact on our ability to deliver.

Shipping changes

Smaller changes are easier to check and quicker to develop. More intrusive new code is, harder it is to reliably avoid detrimental effect on already existing code.

Fixing, testing and shipping a CSS bug can be done almost instantly. Changing core of the widget usually takes a bit more effort to avoid regressions.

Team

Better developers produce better code more quickly.

Some testing is always necessary, but there’s a direct connection between code author’s reputation and experience and trust we put in his code.

Tolerance of failure

Tolerance of users and tolerance of system to change is crucial.

If you provide a service where failure is not an option, then this should affect at least how deeply tested new release has to be. It’s also important for your system to be able to revert to last working state, but sometimes this is not desired and important glitches need to be fixed as they are encountered.

Time

If your schedule is too tight to fix bugs found in new release, it’s too tight for release .

No matter how much you test your software and at Zemanta we do this a lot, new code will introduce new bugs. It will happen that some of them will be too big to wait for next scheduled release and need an immediate fix. If you for some reason can’t afford this, then it may be better not to ship yet.

Pendulum of change

It should be obvious from this list that no factor is set in stone and what might have been a right decision few months ago might not be best one now.

A lot has changed in last few months, so the next time we address this topic, I suspect my opinion will be different than last time.