Not Interested

I'm not exactly sure about how many of the various pieces of software I use frequently that excessively nag me about upgrading to their latest version. It's a lot. Way too many.

I guess many programmers find it really neat that they can call home in their code, check the version number and then automatically inform me that my version is no longer up-to-date. It is a neat trick, the only thing is, I find it exceptionally irritating.

First of all, for most releases, on most of the software out there, it just doesn't provide enough value to offset the risk of upgrading. Risk? Yes, for a larger part of our industry, new versions are just as likely to contain a really bad new bug as they are to work properly.

Upgrading has always been a risky proposition. Even major vendors of seemingly ancient (and stable) products, let clunkers get out the door far too often.

I've been caught enough times, spending hours upgrading, only to find out the current version is so broken that I have no choice but to downgrade to get it back to working again.

Over the years I've just stopped wanting to be up-to-date. They've beaten it out of me. I'd prefer to let someone else waste their life first.

Of course, it is completely different, if the new version fixes something critical (that broke in the last release), or provides an all important feature that I just can't live without. But, over the last few years, almost none of any of my upgrades have held any such promise or potential.

Most are relatively minor enhancements or cosmetic releases. They may make the programmers feel good about getting their code out there, but they offer little real improvement. And even when they do, perhaps a major leap or some big new feature, they are mostly followed with disappointment, not satisfaction. I've come to dread new releases, especially those that involve large, open projects. They often have the worst track records.

The other big thing I find with new releases is that while most programmers can write an algorithm to call home, they utterly fail in writing something that can properly update from one version to another. It's a much more complex problem that is frequently ignored.

Most often, the result is that all of the those neat little customizations that we spend hours and hours tinkering with, get lost. Get flushed away. All of the effort to change and adapt the software, fit it in properly, is wasted.

Because of that, it is no surprise that I rarely customize my software anymore. Pretty much everything is straight out of the box. The default set-up.

In the olden days, when we were actually allowed to use the same version for a while, we'd spend huge efforts getting it set up just right. That amount of tailoring meant that our environments were more adapted to our efforts, that the functions we used frequently were more easily accessible. We sharpened our tools, and made sure they were ready.

Why, I often wonder, do they go through all of the hassle to provide us with a billion little customization options if for the most part changing any of them makes their code unstable, and the change isn't even going to be preserved from version to version? Why waste all of that time providing flexibility that we can't use? Why waste my time, in having to guess which options really do work properly?

I've been burned so often that I'm always shocked when some software product actually manages to get it right. It is so rare.

Nothing is more insulting than being tempted with neat options that don't actually work. It's like spending too long standing in front of a bakery, with no money in your pocket. You can look at all of the delicious treats, but you're powerless to do something about them.

The core of what we do as software developers is to make tools for people. Tools that aren't trustworthy, or waste time, or are just hard to use are not good tools.

It doesn't matter what's inside the code, how fancy the architecture, or how clean the algorithm, or even if the code is elegant. If the outside is dysfunctional, the system is dysfunctional. Users shouldn't have to put up with quirky behavior, or jump through hoops just to do simple things. Ultimately they have a problem which they need addressed. The solution either addresses that, or it falls short.


BATCH ME

It reminds me of a time, long ago, when one of my fellow programmers (and a close friend) was exceptionally proud of the simplicity of one of his algorithms. It was a clean and simple way to take user input, and spend some time in the evenings doing the processing. It could allow a data entry clerk to spend five minutes, queuing up an hour or so in updating work. A huge time saver.

In those days, CPU was always tight, and there was a fixed window each evening for batch processing. The work got done, or it started to interfere with the daytime computing needs.

After many months of my friend's code being in production, proving itself in a real environment, the company hired a new data entry clerk. It seems as if the old one had fallen a bit behind on her duties, so the new replacement -- looking to prove herself -- stayed late one night, entering changes. She stayed really late. Really late.

Of course, the nice, new, clean version of the code featured a 12:1 multiplier in terms of converting effort into batch processing. Not a problem for the old clerk, but a major disaster for the new one. After spending hours and hours catching up on all of the old updates, the new clerk fatally doomed the system for the next day.

My friend hit the roof. He blamed the incompetence of the clerk, and of management (for not stopping her) for "ruining his clean code". He felt that the algorithm was fine, it was a failure in operations that caused the problem. Ultimately, to stop the batch processing we had to erase all of the pending updates. They got lost, became wasted effort.

Once I calmed him down, after a bit of pushing, I finally got him to realize the point that his "nice, clean code", as nice and clean as it was, was just plain wrong! The problem, after all, wasn't solved with nice, clean code. The problem was solved with something that could handle batching updates over a longer period. The rein of the old data clerk was the anomaly and he owned the new one a really big apology. Whatever his code was, it wasn't solving the problem he was claiming that it solved.

Code -- any of it -- from something simple that batches up work, or something that helps to inform us that there are new potential updates that we may (or may not) be interested in, is only really good and useful if it does good and useful things for the user. If it doesn't meet the needs of the users, then it is bad code.


SELF CENTERED

Too often, we see programmers optimizing their code, or their algorithms, or even their interfaces to be what is best and easiest for themselves. Too often we see them subverting the covenant between coder and user in order to "do something" they think the user will want, but is in fact totally wrong. Or annoying, or silly, or just plain old horrible.

Programming, for the sake of programming is a hobby. One that people can (and should) keep to themselves. If you are writing code to make other peoples lives easier, then if the right thing is hard, messy and ugly, it doesn't make it any less right.

As for updates, sure if there is some huge, critical, emergency change, then maybe that justifies bugging me. Maybe.

If I want to go find another version, then that should be my choice. I should initiate it. If I never change versions, then the coders should be happy for me (I've found contentment).

Advice like "release early, release often" is too programmer-centric and not in the best interests of the users. It may make you feel good about getting things out there, but it's bound to cause a lot of anger and apathy in the users.

Computers are tools we use to do things, not mediums through which the programmers should nag us about keeping up with their minor upgrades. That flips the relationship on it's head, and it does so in a very bad way.

So, if I'm in the middle of a task, and I see a stupid dialog pop up telling me I'm a few versions behind, I pretty much know that the programmers who built it were not really thinking about my well-being. I see it as a yet another bug in the system, one that helps me clearly define the real quality of the software.