How not to do a web update

If you’re a major company and your various web-based services have evolved over time, you may have a proliferation of user IDs and some other issues to tidy up. You may be tempted to have a major overhaul.

If you think your reputation among your customers isn’t low enough and you desperately want this update to be an unmitigated disaster, what should you do? If you’re dropping subtle hints about moving towards a Software as a Service model, how can you remind people about the excellent reasons that exist for avoiding dependence on on-line services in general, and on yours in particular? Here are some suggestions:

• Do everything at once. Don’t be tempted to divide this task into manageable portions, or you may have some prospect of success.
• Close down everything for several days. If your customers might have to rely on some part of your web services to keep their products working, make sure you close down that part in particular. Let ’em stew.
• Give the update job to a clumsy intern in your office that has never been allowed near a computer before.
• Failing that, outsource the job to the lowest bidder. Ideally, have it done in a country that has a first language other than your own, to maximise the potential for misunderstandings.
• When the user ID merge is done, make sure it is still broken for some people. Have multiple users with the same ID and multiple IDs with the same user. Some people’s existing user IDs will fail, so encourage them to make new ones and then refuse to allow it on the grounds that they already have an ID.
• Make sure random people’s user IDs work in some places but not others. If they are paying for a maintenance contract, do your best to prevent them from using it.
• Update your discussion groups to a new format. Of course, you should only do this if your existing groups are fast, efficient and reliable, and nobody is complaining about them. If it ain’t broke, fix it. Fix it real good.
• If people have actually asked for any new features, such as signatures in their web-based posts, make sure you don’t provide them.
• Don’t ask for feedback on any suggested changes. Before jumping in with the whole big update, don’t put up a sample discussion group to ensure that it works and that people like it. The slogan “Just Do It” works here, but already belongs to somebody else. Try “Don’t Look Before You Leap” instead.
• Make sure you expose your customers’ private data to the world so they will never want to trust you again. If you can, make their email addresses visible to the spambots. Leave this visible for at least a week to give the trawlers a chance to do their harvesting, no matter how many impassioned pleas people make. You get bonus points if the exposed email address is also the user’s login ID. Spammers, scammers and phishers will love you, but your customers will not.
• Make the new discussion group system slow, unreliable, and less efficient to use than before.
• Ensure the discussion group editor messes up the formatting of people’s posts. Have it insert random junk into the posts and then refuse to let them edit it out. For bonus points, let them edit it out, but then ignore the edits or randomly re-insert new codes.
• Make sure the search engine doesn’t find anything from before the update. If anybody attempts to change the search settings to find all posts, reward them by making sure it finds nothing at all, not even the recent posts it found a few seconds earlier.
• If people are likely to post, say, program code, make sure you wrap it all up into one line to render it illegible.
• If your customers are likely to use certain characters like square brackets in their posts, choose these as special characters in your editor. Mess up people’s posted program code into stuff that looks like a mass of broken links.
• After a week or so, change your mind about the square brackets thing so that people who used that facility for their links now have posts that make them look like idiots. But don’t completely change your mind about it. Break the display of such links, but still encourage the users to insert them. For bonus points, insert each link at the start of the message rather than where the user expects it to go.
• Log people off every so often so they have to keep logging on. Provide a “Remember this” feature that doesn’t.
• If you are silly enough to allow people to keep their old items-per-page settings and you accidentally provide a control panel that works, make up for this by making those old settings unavailable in the control panel. In this way, you will prevent them from using a perfectly functional control panel for fear of losing their settings.
• People who place attachments in their messages deserve to be frustrated, so you should break that feature for a while. Then allow some files to be attached, but mess up their display and randomly refuse to allow people to get at them.
• If you think people might want to paste things into their messages, make it as awkward as possible. Copy and paste has universally worked a certain way for decades, so to keep on doing that is just what they will be expecting you to do. Do something new and interesting instead. Force them to go through a slow and arcane multi-stage process to paste the word “and”.
• Because you don’t have full control over what appears on the screen, it’s much harder to mess up newsreader access, but make sure something makes life intolerable for those people too. Formatting attachments as garbage text is always a useful trick.
• If you have an excellent educational conference coming up and people have complained about the associated web services in the past, take this opportunity to make them worse.

That’s all I have, sorry. My imagination must be failing, because I can’t think of any other ways a company could mess up such an update. Does anybody else have any other suggestions?