a fair and balanced birdthing (raaven) wrote,
a fair and balanced birdthing

Where Incamail failed

Largely in response to the anonymous Incamail fan (or lackey) that responded to my original post regarding their December upgrade, I've written up the following basic guidelines commonly used by professional IT folks. All you IT folks on my FL, please feel free to add to or correct my version of the Right Way to Do It in comments.

a - There is a very simple, very common process called change management (or change control) that professional business IT groups follow. It is designed to make upgrades and other changes to the system as seamless and trouble-free as possible for the people using said system. It's factors include:

1-Clear and timely communication to the user that a change will be happening.
2-Clearly stated goals/results of the change (both to the user and internally). Ideally, these goals should involve a noticeable, positive change for the user. If it doesn't, it should at least involve minimal inconvenience to the user.
3-Setting a clear start and duration time for the change to occur.
4-Having a "rollback" plan that puts the old, WORKING system back in place in the event that the change exceeds the projected downtime or fails in any significant manner.
5-Communication, communication, communication with the user.

b - In the world of professional code and software design/writing, there is an equally simple set of guidelines that professionals follow for best results. They include:

1-Have a project manager who is not (or is only minimally) involved in writing the code. This person's job is to keep an overview of how the new code will effect the user's experience, and making sure that the code-writers understand the needs of the users (also that they stay within time and budget limitations, but that's an entirely different set of issues than I want to focus on here).
2-Once your basic code is written, set up a test environment. This is a mock-up of the eventual live environment that doesn't effect the regular user.
3-Use this test environment extensively [and if possible, have a small group of regular users (NOT code geeks)] use the test environment and report any problems or bugs to the project manager (this is called beta testing), who will then shape a plan for the coders to follow in overcoming those issues.
4-Once the coders believe they have overcome the original issues, it's time to repeat steps 2 & 3. If they're very good (and very lucky), the product will now be ready to go live...time for the change management process to take over. If not, steps 2 and 3 are repeated until either the code works flawlessly for the end user or the project manager decides that it's futile and cancels the change/upgrade.

Incamail's recent upgrade failed all 5 points of guideline a. In fact, from all evidence, it would seem that they have no idea that this concept even exists.

-There was no notification previous to the upgrade. Users were simply suddenly presented with a page saying that the site would be down for a few hours for upgrade.
-The original "few hours" they expected to be down turned into over a week, with no update in the notice posted on their sign-in page.
-When they finally came back up, the old bookmarked sign-in page still showed only a 404 error. This may still be true...but I fortunately thought to go manually to their homepage and found it up and (sort of) working.
-When they came back up, the unrestricted mailboxes were suddenly on restricted setting (with no way to change them)...AND THIS IS STILL, a month and counting later, THE CASE. Additionally, email that had come in meanwhile (even when from the same, exact address) was randomly shuffled into both the known and the unknown folders. In other words, all fucked up. Still.
-There have been no communications from Incamail to it's users as to when these problems may be fixed.
-The site isn't noticeably faster. It's less accessible (having gone to an IE-only format) and less flexible. Upgrade? Ahem. I don't think so.

If they followed any of the points of guideline b, they did a damn sloppy job of it. Personally, I doubt they bothered...the site now works like a beta-test that no one's been told is a beta-test.

These folks definitely need some professionals involved in their project...'cause it's clear that they're not "getting it" on their own. I'll continue to stick with them in the hopes that they'll improve...for awhile, anyway. But dude, if these guys don't start flowing quickly, they may cause what started out as a really nifty idea and good service to nose-dive off into internet oblivion.
  • Post a new comment


    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded