How to Infuriate Your Custom Software Client in Three Easy Steps
October 11, 2011 1 Comment
My wife just asked me to take a peek at database application that her organization had custom developed using a local Ghanaian consultant, “Andy”. They have some issues with excruciatingly slow reports and an arduous data cleaning workflow that involves exporting to Excel to find errors and then picking through screens to fix them in the software. The application is a WAMP stack web app and running standalone on a single analyst’s Windows desktop and the data set is pretty small. They need a much more efficient batch data access mechanism and they need to be able to run ad-hoc queries from time-to-time without signing a new support agreement to have additional features baked into the system. It is a custom-built system that was bought and paid for over a year ago.
My idea was to set up MySQL Workbench so that they could do some back-end data cleanup in a spreadsheet-style view of the data tables. This would also allow them to issue ad-hoc SQL queries to so that they can respond quickly to requests to slice-n-dice their data in new and interesting ways. Unfortunately, it turned out to be not so easy because Andy has done everything in his power to lock his clients out of the data system they paid him to develop.
#1: Gratuitously Encrypt the Source Code
Despite having been contractually obligated to provide complete source code, Andy encrypted the entire application with SourceGuardian. This is deeply uncool to do to a pure custom software consulting client and also an explicit breech of Andy’s terms of reference. Furthermore, the application is 99% Pear PHP modules. It’s just a login to an Access-like switchboard with what appears to be one data entry screen per table and one export-to-CSV per table. Most of what is encrypted is Pear modules and just a handful of PHP scripts for the data entry screens.
#2: Hold Your Client’s Data and Configuration Hostage
Andy the Consultant set up the WAMP stack on the Windows box and installed the application. He did not give anyone the root password for MySQL. Among the pile of encrypted PHP is the uselessly named config.php which probably has the database connection string in it and if not there in one of its siblings. There’s no way to know a priori if Andy has created an account for the application or if his application is using the root account without resetting the root account experimentally and seeing if it breaks the app.
#3: Refuse Access to Both Source Code and Data
My wife called Andy to get the MySQL root password and he refused, citing professional IT ethics and a technicality of the reporting structure of his contractual agreement: to wit, my wife is the project deputy director but Andy is a second-tier subcontractor so his agreement is technically with a subcontractor working for my wife’s company and hence it is unethical to release any information directly to the management of the company overseeing said subcontractor. What?!
This is egregiously forced lock-in. The data and source code are hostage to the whim of the development consultant who has made himself irreplaceable as long as the data has value.
There is an effort underway to apply some Ghanaian social pressure to Andy as well as the implied threat that he is risking freezing himself out of the USAID and foreign donor market in general. That said, as an owner of a software company that does commercial custom development, I myself am deeply offended. Even if Andy had an agreement where his entire work product remained proprietary there is just no circumstance I can envision in which it is ethical to lock up a customer’s data.
In any case, this data isn’t going to stay locked up. If Andy doesn’t cough up the MySQL password, I’m just going to capture it out of the raw packet frames using RawCap and open the resulting capture into WireShark to take advantage of the built-in MySQL protocol filters.
Don’t Let this Happen to You
Word to the wise. When having custom software work done—especially in an emerging market context—you need some Independent Verification and Validation that you got what you paid for because you have very little leverage over your consultant after he has been paid.