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.

Disgusting . What does it take to get rid of this incompetent egotistical idiot?

I recently came back from Berlin, where I publicly asked John Lily why haven’t they integrated Greasemonkey into Firefox . Wrong question can hardly lead to right answer. What I really wanted to know was:

“Why doesn’t Mozilla integrate Greasemonkey-LIKE functionality in a browser?”

Browser is at the farthest reach of web creators. It’s them who decide how a page will look like when it gets loaded and what visitors will be able to do with it. User actions that were not anticipated by page designers are limited to printing a page, tweaking its display a bit with user style sheets, seeing its source and copying text elsewhere.

Browser is also an application that is loaded on someone’s computer and belongs to him, as much as software can belong to somebody in EULA-infested world. Not every browser is equal, but pretty much all of them limit what you can do with page (beyond its creators intentions)  to above actions. The real question than for me becomes:

“To whom does a browser belong to?”

One reason why I love Greasemonkey is that it enabled me to fix and change pages that I find lacking. Not every page has navigation where it should be and lots of them display parts of text in illegibly small letters. It can also help me plug different services together. It is indeed geeky, as Brady Forrest observed, but useful implementation doesn’t need to be. I find Platypus extension a good first step to how a browser could further empower its users in customizing pages even further to their needs.

I thought about downsides to this since Thursday and I’m failing to find anything substantial.