Over the last several years, I’ve observed several trends in the online world that exemplify why it’s important to be careful who you trust to develop your online application. To support my opinion, I’ve included three examples.
Evil 1. Not being careful with someone else’s data. I could site 1,000 examples of a company or government agency that screwed up and exposed personal and/or financial data. For the sake of your time (and mine) let’s look at the recent case of the FAA. In this instance the data breach exposed financial data for more than 45,000 FAA employees and retirees. Indeed, according to another article covering this incident [1], the FAA was actually warned about its data security issues, but ignored the warnings. Further, it took the agency a full week before they notified its employees of the breach. This example shows that other people pay the price whenever we — developers and technology professionals — don’t take our responsibilities seriously.
Evil 2. Intentionally and arbitrarily excluding a portion of your potential user-base in order to save yourself time or effort. Inutit’s Quickbooks software has implemented this practice. An error occurred that made linking to a financial institution unusable. Intuit gave us a “choice” — pay per incident to fix the issue, or pay for an upgrade and receive a year of support — both were the same amount. The new version is available online, but when the primary user attempted to login using Mozilla Firefox on Ubuntu Linux, he received a message stating logging in was not possible from an unsupported platform. This type of non-service is what we like to refer to as FAIL (yes, the all-caps is necessary for the proper effect!). I installed the User Agent Switcher [2] extension for Firefox, which fooled the site into thinking we were using IE7 on Windows XP. The user was then allowed to login and complete his transaction without a problem. The reason the “unsupportable platform” code was there was most likely to reduce the possibility of support calls for non-Windows platforms. But, let’s be honest. People who are using Linux on their desktop probably aren’t going to call customer support over an issue anyway. In addition, it probably took more time to add the code to refuse login than it saved in support time!
Evil 3. Vendor lock-in. Vendor lock-in is the practice of making it difficult or impossible for your customer’s to choose a different service provider. We’ve all been in this situation before — you use a product, you build up a chunk of information you’d like to carry to another program or device. However, the designer of the original product offers no way for you to export “your” data to a neutral format. Recently I ran into this when I was helping a friend. They have been paying monthly AOL fees for several years, when the only AOL service they were using was email. We tried to move their account to g-mail. Vendor lock-in became evident when attempting to get a contact list out of the AOL email software — no functionality is provided for this service. To solve this, I wrote a BASH script in Linux to parse an HTML copy of the address book, and converted that data to a CSV that could be imported into g-mail. Interestingly, AOL does provide a way to “import” contacts into their email software!
So, there you have it. My short list of things in this world that need fixing. They all could be fixed by focusing on the customer when writing software.
Very good post. I totally agree about Intuit alienating Quickbooks users.