I have been a software engineer now for 25 years. In that time, I have frequently been appalled at the way many supposedly reputable IT companies treat their unsuspecting customers. This article is intended to help redress the balance by providing the customers with some understanding of what IT companies will do if they're allowed to get away with it.
The way this works is that the customer is sold a licence to a company's product, and charged a fee for the work required to tailor the product to the customer's requirements. Now, there's nothing wrong with this - if that is really what is happening.
The problem is that the product that has been licenced to the customer may not exist, or may exist only in part. The missing part is developed during the customisation project, whose price has been set accordingly. This new software then becomes part of the product to be licenced to the customer. So the customer has paid for that twice - once in the licence fee, and once in the customisation fee.
This is an extension of the double paying scam. The customer is induced to enter into a maintenance contract. The problem here is that software does not break, nor does it wear out. If it is ever found to contain a fault, then that fault must have been there from the beginning. If it is in the part that was actually written during the customisation project, then the customer has paid for a licence to the faulty software, for the development of the faulty software, and then for the correction of the faulty software.
Not all customers fall for this one. Acceptance tests are a final quality control measure, intended to determine whether it is likely that the software will perform properly in practice. As such, the tests should not be specified by the software supplier, and on no account should the software supplier be allowed to run them. I've heard of a set of acceptance tests run by a software supplier, where one of the developers was manually fixing errors in data stored in the database as the tests were being run.
One of the bullet points in a requirements document is likely to be something along the lines that proper user authentication take place, and that the user's ability to perform functions on the system depend on privileges assigned to them.
No doubt the software supplier has ticked the check box, and it will look as if the software does what is required of it.
The pertinent question is "where are these controls enforced?"
They must be enforced by the server. There are supposedly secure systems out there where the security is in fact enforced by the client - that is, by the software that is running in the user's workstation. This is not security at all. A suitably skilled user can tamper with the software and thereby override the security. Whether this matters is arguably a judgement call. Still, for some purpose, such as the storage of medical records in a large organisation, client based security would clearly be unacceptable.
Have you been assured that the work on your project will be performed by skilled engineers? Maybe the company has specified the makeup of the project group, which contains several senior engineers. But what is a "senior engineer"? The recently defunct Objectif Telecommunications Ltd defined a senior engineer as one who has a minimum of three years experience. Three years? Can you imagine flying in an aeroplane designed by people with three years engineering experience? Having your software built by inexperienced engineers can seriously damage your wealth. You'll pay in the form of poor performance, inconsistent behaviour, and frequent faults. In addition, there will be subtle and not so subtle security holes. One example of this became apparent recently with an Internet shopping system that stored the prices of items in hidden fields of a WWW form. This is certainly a simple solution from an engineering standpoint, but has the rather substantial problem that if the user changes the values of the hidden fields, then the system will sell the item to the user for whatever price the user chooses. It may not even be unlawful for the user to do this.
IT companies - at least the ones prone to perpertrating these scams - are frequently short of cash. One way to get some cash out of the customer is trigger the installation milestone payment by installing the software. So that's what they do. They install it. This does not mean that it is ready, or that it will work. The supplier cannot admit that, though, so acceptance testing starts. If the software passes (the acceptance test scam), then the customer tries to use it. That's when the faults start to show. The software may in fact be totally unusable, but this only becomes clear after the customer has suffered considerable pain and cost, and the milestone payment has been made.
Software suppliers almost always underestimate the true time and cost of producing software. In part this is because of the double paying scam - in reality there is more work to be done than is being disclosed. Some are notorious for this, particularly where the software is being written on a time and materials basis. The first the customer will know that the software is going to be delivered late is when the due date for delivery passes. The slippage will be a month - then two months - then four months. The customer may also fall for the installation before it's ready scam.
The sad thing is that the software suppliers often believe their own lies. In attempting to run the project as if the original promises on time will be kept, the supplier will cause the project to be even more delayed than it would have been if an honest estimate had been used.
The contract should require that the licenced software part of the application be installed as soon as the contract is signed. If this is not practical, because the hardware is not available, then the licenced software should be supplied on the computer readable media (probably a CD or DVD these days) which should be used when the rest of the software is ready. If the supplier tries to avoid this requirement, then the customer can reasonably suspect that the software does not actually exist yet. That said, it must be accepted that the customisation may entail small changes to the licenced software. The supplier should be willing to demonstrate in due course that the software supplied just after contract signing, and the software ultimately delivered, are the same except in minor details.
To some extent, a maintenance contract is more about paying for a prompt response than about paying for corrections to software. Still, this should be for obscure problems, not run of the mill programming mistakes.
Make the final payment contingent on a certain period of production use without any faults being found. That should cause the supplying company's CEO some sleepless nights - unless the company really is reputable, and does not deliver bug ridden software.
Get a technical expert not associated with the supplying company to specify the acceptance tests, and to run them. Provided they fall fairly within the specification of the software, the supplier should have no cause for complaint.
As an aside - wherever the user can enter text into a field, make sure that you try text containing things like "why is <b>this</b> bold?" and names like O'reily. In the former case, you may find that retrieving the first text later display it as "why is this bold?". If it does, then you have what is called a cross site scripting security flaw, which is caused by naive programming practices. The second case may break the application in some way, or you may find that part of the name is simply lost. This is a sign of an SQL insertion security flaw, and is a indicative not just of sloppy programming, but extremely ineffecient design
This is a tough one for a customer to spot without skilled technical help. However, if the supplier is asked whether the security is implemented in the client, you would at least have a written answer that could be used as evidence later if necessary. Not so many people are willing to outright lie.
Get a definition of the term. If there is not at least one person on the project team with ten years experience, then you have problems.
Do not have an installation payment milestone, nor a "going into acceptance testing" milestone.
This is probably the most difficult to handle. Even totally reputable companies are going to be uncomfortable with contracts that have severe penalty clauses for late delivery. Estimating software projects is not an exact science. Also a company that gives a true estimate may very well lose out to a competitor that underestimates.
The best you can do is to try to measure how confident the supplier is in their estimate. The more resistent they are to penalties that rise with the extent of the delay, the less confident they are in their estimates.
One side note here: The word "aggresive" in discussion of estimates and timescales is code for "it will be late, and then some". Some people think that the estimate has some affect on the time required for production. It does not. The time required is whatever it is. The estimate is merely an attempt to guess the extent of that time.