A little while ago I was at a house party. I got talking to a fellow who does creative work for marketing campaigns. I asked him if it's true that two thirds of the money spent on advertising is wasted. He agreed that it was.
He said with advertising you can have it fast cheap or good, pick two. That rule applies in a lot of areas. I remember the first time I saw fast cheap good. It was a sign on the wall of an auto body shop when I was a child.
A veteran developer at the office who has team led some key projects in company history had a slight twist on it with software projects. In a software project ther are four variables that are naturally balanced against each other. They are scope, schedule, resources and quality.
Scope is the features contained in the release. Sometimes the scope is based on a sale or a contract agreement so all of the features must be implemented to get paid. Sometimes with a more internally defined project there may be room to cut or scale back features so the project can be completed within the desired timeframe. Problems can occur in a software project when the original scope expands. If scope increases then this must be balanced against the other three factors. The problems can occur when features are just "added" but no allowance is made in terms of resources or schedule for the new work.
Like scope, schedule is often pre set based on external agreements so cannot be changed. Sometimes in a project this is the one variable which does not change throughout. Often the software team is evaluated by meeting scheduled dates above any other objective. Of the four project variables schedule is often the most difficult one to change after the project begins.
Scope and schedule are often balanced against each other. I've been on many projects over the years where somebody wanted to add something during the project. When the project manager informs that any addition in scope can only be accomodated by slipping the schedule, the feature request goes away. I can recall many instances over the years where the person requesting the feature changed his mind when faced with a schedule slip. I can't recall a single time when someone agreed to slip a schedule of an in progress software project in order to add new features.
Resources generally means the head count of people working on the project. This can be increased somewhat if necessary. But as Brooks points out, you quickly reach a point of diminishing returns when adding resources. One type of resource which is often added is overtime. That allows the team to stay smaller and more manageable while being able to get more done in the same amount of calendar time. Overtime does have its costs though as quality tends to slip in the long sessions and the extra hours tend to be less productive per hour as it adds up.
Which brings it to quality. The reality is that quality tends to be the easiest place to take the hit on when a project is too big and too complex for the time and resources allocated. The thing about quality as opposed to say features or schedule is that the programming team does not have to get permission to slip on it. It can just happen and nobody knows about the quality issues until after the fact.
Unlike a schedule slip or missing features, a quality shortcoming is not immediately obvious. So it's easier to maintain an illusion of a successful software project when in fact the project was not as successful as hoped. A quality slip can take different forms besides obvious defects in the running product. Low quality can appear when the code is poorly structured and hard to maintain. Code copy and paste is used instead of refatoring common pieces. Javadoc and JUnit is skimpy or skipped entirely. Quality can appear as an unintuitive user interface lacking polish. Quality problems can appear in the form of low performance or crashes under load.
For the develment team lead and manager, when a software project is getting started they need to communicate to the stakeholders the factors that are always balanced. Sometimes the people outside the development team want to push for lots of major features and an aggressive schedule. The software team needs to communicate clearly up front when it is obvious that the hit will be on quality if that is the only factor which is allowed to vary.
