(c) Dr Kymberley Wilson , 1996, revised 2009
This article is a light hearted summary of my views on software development after nearly 40 years of writing programs and over 20 years of specialising in that field..
Is size important?
There are cases where a software package can only be developed by a large team of analysts, programmers and other computing specialists, either because of the complexity of the product or time constraints. However most applications are developed by a single developer or a few developers working together. While 2 developers can produce more output than one, they probably can not produce twice as much. As soon as a second person is involved the overhead on a project goes up as they have to keep in touch with each other's work as well as doing their own. Concepts which may be intuitively and fully understood by one person may take some time to explain to others and further time is needed for the project leader to check that the modules developed by others will integrate into the system. Version control becomes an issue at this stage to ensure that the latest versions of all the modules are used and that only one person is working on a particular module at any time. Most of these issues do not occur when a single person is developing the system.
The main advantage to the client is that the second team member may be less experienced and, hence less expensive, than the project leader.
The dreaded bus
Given that only one or a few people are actually involved in creating the software, is there any advantage to a large company over a small one. The usual question is "What happens if you get run over by a bus?" Apart from the fact that the affects to me and my family are probably more drastic than to your software project, it is a reasonable concern. Essentially, should the developer become unavailable for any reason the project will suffer, at least to the extent of some delay. A replacement developer will need to be found and will need to work out what has been done and how to proceed with the project. This would be the case whether the developer was from a one man company or an agency with hundreds of staff. The advantage of a large company is that they would find the replacement for you, whereas you may need to find the replacement yourself in the other case. You may be lucky with a large company and get a replacement who is somewhat familiar with the style of the original developer, which could also save time.
But here's the catch - "What if you don't get hit by a bus?". In this case you will have the same developer - the one you chose to undertake the project - seeing it through from start to end. With a large company, there is no guarantee that your developer won't resign, or even be pulled off your project to be put on another. Then you have the same delay and retraining as for a disaster, and you may not have too much control over the replacement staff member from the larger company. In fact there was a case where a large company had developed a system and was awarded a contract for the next phase of development to some (possibly large) degree due to the fact that their developer was familiar with the client's business as well as the program. The developer resigned within a week of the contract being awarded and never worked on it.
How long's a bit of string? ( or Jim'll fix it)
Software projects can be undertaken with one of two, usually mutually exclusive, goals. The first is to produce a system the meets the specifications defined before the development starts and the second is to produce a system that actually does what the user wants it to do. The difficulty with software development in general is that often the user doesn't really know what he wants until he sees what the developer can provide. This often leads to further enhancements to the program until the system finally converges on the users needs.
When costing a project the first approach allows a fix price quote to be derived, whereas the second approach does not and there are many cases of problems with both approaches. One government agency finally received their software (late) only to find that while it met the specifications it was effectively unusable, and tales of Blowouts in cost are legendary - Fremantle Hospital springs to mind.
I prefer the iterative approach since the client can correct and enhance the product during the development cycle and has a much better chance of achieving a useable goal. In a major development for Main Roads, one of the most useful options has been the ability to map the data and this was not even suggested until about 80% of the way through the project.
Costing is always a sensitive part of the project. Clients who require a fixed price usually pay too much, since the developer has to estimate the time involved, convert that to dollars and then add on enough to cover contingencies. If he's lucky he guesses a too high figure that the client accepts. If his guess was low then he has to cut corners and produce the minimum required to meet the specifications, or else take a loss. The latter doesn't lend itself to an emotional state that leads to quality work.
On the other hand, the client must be careful that an hourly rate contract doesn't blow out with frills that are not required for the successful completion of the project but which are still a chargeable use of the developer's time. This boils down to trust and performance reviews between the client and developer.
What price quality?
One factor that has become more common lately is a quality control certification. What does this require? First of all it really requires a company to have more than one person, which immediately puts it out of reach for me, and then a large amount of money for the auditing and follow up certification. Does it improve the quality? I doubt it.
Many larger companies have quality certification and this guarantees only a minimum level not a maximum. Quality is in the finished product, which depends on the individual developer and the interaction between the developer and the users, not in the certificate on the wall.
I suppose the most telling comment on the QC issue was a quarter page ad in the yellow pages, a few years back, in which some manufacturing company had proudly displayed their QC logo. Unfortunately it was UPSIDE DOWN.