Tags

As a general rule, I don’t like change. When things were just fine the way they are, I don’t want to have to deal with the new and different. Even when things aren’t just fine the way they are, I get used to them. Don’t go stirring up trouble.

Who can remember the days before internet, weekly (often automatic) updates, and continuous, on-line support? When problems were found in a piece of software, a new version had to be prepared, burned onto CDs, and shipped off to every customer with an installation. It was a big deal. So big that, as a user, you had to consider whether or not it was worth destabilizing what you had going to fix what, for you, were perhaps minor issues.

Worse still, the quicker and easier solution – the patch – could be an even scarier prospect. You were essentially creating your own “version” of running software locally – a version that, by definition, hadn’t had the kind of QA rigor that proper shipped version should.

The result is that, once we were using software that (mostly) worked, we learned to stick to that version. If there were minor issues, but those issues could be worked around, we grinned and we bore them. We didn’t patch because “there is a new patch.” We patched only when we had a problem that we hoped the patch would fix.

These days, we’ve probably acclimated ourselves to constant change within the software that we use. The choice to apply the latest patch is routine and many installations are set up to patch automatically. Certainly when it comes to things like client-server, cloud-based computing, or even just a simple website-based or phone apps, updates can and do take place without us even being involved. It is certainly nice that bugs are patched quickly, often before most users would have a chance to have stumbled across them.

This “bug fixing” is also accompanied by a “continuous improvement” of the user interface and customer experience. From a marketing perspective, this sounds like a great idea. If you’re not moving forward you’re falling behind, right?

How often are my complaints, here, related to features that – far from being broken – were much better the old way (at least to me). No, I don’t want all my online tools to look like Geocities… but I really get stressed by rugs being so frequently yanked upon while I’m trying to walk across the room.

I regale you with that long introduction mostly to say that the problem I had with footnotes is not only still there, it may be worse than I thought it was. I just (think I) saw that, even where an HTML tag has been created using the newly-implemented interface, future edits to the post might find that that datum is lost.

I haven’t exactly pinned down when an HTML tag persists and when it vanishes. Then again, WordPress isn’t paying me to do their QA for them so I don’t really feel like I have to. Let’s just say I’m still coming across the problem almost every time I work on an older post… but not necessarily every time.

Even while I was stewing about this annoyance, I found a new one to bug me. I noticed that the “pingback” function is, once again, shut down. For those who aren’t fellow WordPress junkies, this is the feature where links to other WordPress posts are “noticed” by virtue of a comment automatically posted at the link destination. The feature seems to be designed to allow one blogger to acknowledge the attentions of the other through the click of an approve button rather than writing some kind of “hat tip” post. Whether it was supposed to work this way or not, I’ve come to appreciate its utility as a “forward link” between my own posts. That is, any link to an older post automatically creates a corresponding link, via the comments, back to the new one. The circle of blogging life is complete.

Or at least it was until a couple of days ago.

This has happened before, although I let it pass without comment last time. Pingbacks were not working for a while and then suddenly they were again. All indications are that this change was not intended.

One has got to wonder what it is that WordPress thinks they are fixing with all of these code changes. Are they really trying to deprecate features, or as has that just been the unintended result? Are these merely “fan outs” from semi-related changes that weren’t properly vetted before being implemented. It’s all the worse if real bugs are introduced while making dubious user interface improvements, changes to something that worked just fine before the “fix.”

Such a lack of QA process is indicative of shitty software management all around.

I may have complained, when it was happening, about when the Netflix queue-management interface became unusable. It appeared that a change to sexy-up the look, to emulate a state-of-the-art iPhone app, required so much in computing resources that Netflix became impossible for me to use. I could rarely see more than a dozen or so movies out of my saved list. I was thinking back then that, just maybe, this was a all a software development/support team run wild. Does a department, once created, try to justify their existence (and maybe even continued growth) by ginning up and taking on new and wonderful features? Are these features driven by the programmers rather than the users (wouldn’t it be cool if…)? Would those new features ever be greenlit if it were necessary to justify them in a cost benefit analysis?

Or to go back to my original gripe, how was moving the HTML ANCHOR interface to its own subscreen supposed to increase revenue for the WordPress organization? I cannot imagine.

I don’t for a moment believe that angry tirades about software support on my lightly-read blog are going to hasten those problems being fixed or otherwise improve the tech world. The fact is, sometimes I just like to complain.

Since I have my own forum, I do just that.

[edit – Between the time I started typing this post and the time I published it (a couple of days), the pingback function began working again. I know because this post created such a pingback when I hit Publish]