Technology Hints
Need a database to store students, quiz scores, etc? Just roll your own! Why would you use a COTS RDBMS when your in-house coders can write something nearly as good at a FRACTION OF THE COST? If you must use COTS, be sure and use something suitably brain-damaged, like the Borland Database Engine. Be sure to repeatedly make references to "re-indexing files" or "repairing data" in the manual, and include a utility that will perform this function while making hundreds of redundant backup copies of the data all over the Customer's server computer.
The client/server metaphor is overrated-- just put your data in a file on a shared "network drive" and then have an elaborate locking mechanism. No worries about doing that at all. Be sure not to allow the use of UNC paths-- everything should require a "mapped" "drive".
The standard user interface widgets in whatever operating system you're targeting are no good. Your coders should spend an inordinate amount of time making a custom user interface that looks nothing like any other operating system. Avoid all standard keyboard shortcut conventions. If possible, just avoid all keyboard shortcuts.
Make sure to require that students using the software must be "registered" in the application's database first. Offer no facility to disable this valuable functionality. Additionally, be sure that there is no way to bulk import students into the database. (This is usually an important reason not to use a COTS database. You wouldn't want the Customer to figure out how to end run you and import data into the application on their own.) Finally, require that each student have a password, and make sure that the password meets a complexity requirement sufficiently difficult as to meet NSA security guidelines.
Provide no documentation on backup of your data files and disaster recovery. If possible, thwart disaster recovery attempts with copy protection mechanisms that refuse to read data files made by prior installations of the application.
Trap all errors and always present a message indicating "Out of memory". If possible, include an instruction to the end user to contact their local support personnel in this message. If you must output errors other than "Out of memory", be sure to only output cryptic numeric error codes. If possible, output these error codes in hexadecimal so that users are less likely to transcribe them properly.
If you use standard protocols like FTP or SMTP, be sure and implement them yourself rather than using a tested and verified third-party library. Most of the information in RFC's is optional, and you don't really need to implement your clients or servers to the RFC specifications. If you're going to send SMTP email, for example, simply open a socket to port 25 of the intended mail server, and blast the entire transaction ("HELO", "MAIL FROM", "RCPT TO", etc) in one fell swoop, and don't bother waiting for banners and responses back from the SMTP server.
NEVER package the application with a standard packaging tool (RPM, MSI, etc). Make the application as resistant as possible to attempts to package it with a standard tool. Try and have the program's main executable move around, and modify itself on each run.Include self-updating functionality that cannot be disabled, automatically downloads new versions across the Internet without user intervention, and presents cryptic messages to the user. If at all possible, make this a separate program from the application, require that it run at startup, and have the application replace any configuration that starts the update program each time the application is started. Make sure that any updates automatically update the underlying database schema and prevent un-updated copies of the program from running properly, preferably including the display of an "Out of memory" error.
If you can, purchase the entire application from a third party without getting access to the source code. Ask the third party to destroy all copies of the source code and kill any developers that have knowledge of the internals of the product.
Tech Support Hints
Be sure you don't put any pertinent support information on our web site. If at all possible, build an elaborate login system that requires the user's serial number, a "customer password", the answer to a "secret question", and completing a marketing survey.
If any of the Customer's qualified support personnel call for support, start by routing their call through some random day laborers you picked up off the street. Once you get through them, route them to "level 2", where they will need to wait for a callback. Days or weeks later, call them back. Be sure not to log any case notes from the "level 1" experience so the Customer can experience the joy of re-telling all the pertinent details to the "level 2 technician". Be sure and have your "level 2" technicians repeatedly interrupt the Customer with helpful "feedback" and suggestions. Find any excuse to blame "the network" at the Customer site. Under no circumstances should you, at any time, actually identify a device, server, operating system, any tangible article, or any specific item as cause for the observed fault. Simply repeat "your network is at fault". The application is never at fault.
If Customers email support requests, no matter how detailed, well thought out, and thorough, always reply with a terse request that they call the telephone technical support line, as technical matters are too cumbersome to discuss via any communication medium other than undocumented voice conversations.
All Customer end user support requests should be directed to the Customer's own support personnel. The end user should be specifically instructed to indicate that "the network" is at fault, in accordance with the aforementioned support resolution process.
Hints for End Users
The user must be sure to fail to understand that their local support personnel do not have the source code to the application and do not have divine knowledge of the inner workings. Further, the user should assume that the support personnel can replicate any problem condition that the user experiences. In addition, the support personnel should be assumed to be able to read the user's mind, and as such, no record of error messages or specific circumstances in which the issue occurred should be communicated.
The user should assume that the application is 100% bug-free, and that any error conditions observed must be the fault of the support personnels' incorrect deployment of the software, incorrect configuration of "the network", personal preferences in music, movies, or food, or their very existence. In no case should the user ever accept that a bug could exist in the application.
The user must always indicate that every software application is critical to day-to-day activities, and without access to the application all other educational activities will grind to a halt. If possible, users should complain to superiors loudly.
