I like to cook. I hate washing dishes. Sometimes I let dishes pile up in my sink and on my countertop. When I stagger downstairs for breakfast, sometimes I have no clean dishes, and I have to rearrange the dirty dishes in the sink to find dishes to wash and to make room to wash them.

Sometimes I'm good, and I put my dirty dishes in the dishwasher immediately. My sink's always empty, so I can use it if necessary, and my cupboards are full of clean dishes and pots and pans and other cooking utensils. I don't have to set aside extra time to get my kitchen in shape before I can cook.

A few of my friends run marathons. They train every day for several months, though usually not the full twenty-six-and-a-half miles on every run. They don't show up on race day having run not at all in the past year, expecting to finish. They put in a little bit of work every day to prepare.

I write novels as a hobby. My goal is to write a thousand words every day. That takes somewhere between half an hour and an hour and a half every day. In a year, I can write two novels at this pace. It's possible to write a novel in a month, but that's some three thousand words every day. A professional writer with a great outline, a good sense of character, and the discipline that comes from months or years of writing every day could make that work, but not so anyone else.

When I write code, I run my tests every time I make a change to the code I'm testing. Sometimes that's every few seconds. I could run my tests only when preparing to release a new version, but every time I've done that, I've spent hours debugging problems that would have taken me seconds to fix if I could trace them down to the single line of code I changed since my last successful test run.

In all of these endeavors, one step at a time adds up to big progress over time. Writing one word isn't difficult. Washing one dish is easy. Fixing one failing test is trivial. Running one mile is much less daunting than running twenty six. This isn't a new thought. It's barely an interesting thought.

I wonder, though -- what is so different about upgrading to a new release of software every month that's so difficult the only way to do it is in a long-delayed, long-planned, big thud upgrade every two or three or five or ten years?

It's not as if I wash any fewer dishes one at a time than all at once, or run any fewer steps one mile at a time than twenty six at a time, or write any fewer words a thousand at a time than a hundred thousand at a time, or write any less code two and three lines at a time than two or three hundred at a time. The amount of work accomplished tends to scale linearly. Maybe upgrades seem daunting and weird and difficult because big bang all at once once in a blue moon upgrades are simply too big to be anything other than difficult. Maybe small, frequent upgrades can be so boring and dull that they're as easy as putting your spoon in the dishwasher after you finish eating.

Certainly with Parrot we've discovered that releasing a new stable version every month is much easier than releasing a new stable version only once or twice a year. It's documented. It's automated. It's repeatable. It takes some time, but it's fairly boring how uncomplicated it is.

What makes the other side of the process -- users upgrading -- any more difficult?