If there's one single thing you should know about software engineering it's the Constraint Triangle (see Figure 2.1).
Cost is the measure of how many programmers are hired to be on your team. Time is the measure of how long you have to finish the project. Quality is the measure of how many features your software will include and of how extensively it will be tested.
Controlling time, cost, and quality are all important goals. You want to manage time so that your project will be ready by its deadline. You want to control development costs so that the project will be affordable and even profitable. And you want the quality of the software to be good enough to make the software attractive to users.
In a fantasy world, we'd like for our projects to be done instantly, to cost nothing, and to be of infinitely good quality. But in the real world, we have to compromise. The reality is that in order to change one of the time, cost or quality goals we need to provide some slack by adjusting one of the other goals.
You can decrease the time needed for your project, but to do so means increasing the cost by hiring more programmers and/or reducing the quality by eliminating features and perhaps cutting corners on the product testing.
You can reduce the cost of your project by using fewer programmers, but this means you'll need more time and/or to reduce the quality.
You can opt for a very high level of quality, but this means your project must take more time and/or cost more.
Any change to one goal must be compensated for by a change to one or both of the other goals.
If you let your customer (or your manager) arbitrarily specify all three corners of the Constraint Triangle, your project is doomed to fail. Any change to one corner must be balanced off by changes to the other corners.
The moral is that if your project is to be successful, you must be permitted to make a realistic assessment of cost, time, and quality, and you must be permitted to make the necessary adjustments to at least one of the goals. Unless you are allowed to realistically adjust at least one corner of the Constraint Triangle, your project will fail.
In the 1990s, NASA briefly adopted the slogan: 'Faster, cheaper, better.' This was followed by a series of unsuccessful projects ? and then they abandoned the slogan. It's important to realize that, pushed to the limit, the 'Faster, cheaper, better' slogan is impossible to satisfy. It's as absurd a statement as 'I can fly' or 'I can turn rocks into gold.' There's a saying among software engineers that a correct statement of NASA's praiseworthy but impossible goal is this: 'Faster, cheaper, better: pick two out of three.'
At some point in your career you're likely to be saddled with a manager who thinks a rah-rah, can-do attitude is enough to get things done. Always speak up and protest if you hear anything like 'faster, cheaper, better.' Don't accept it if your manager suddenly decides to halve the cost, halve the time, or double the quality without making any compensatory changes to the other corners of the Constraint Triangle. If you let so foolish a plan stand, it will come back to haunt you. Mention the Constraint Triangle and draw a picture of it. Explain that it is a simple impossibility to arbitrarily specify all three corners.
Unless you are in a fairly powerful position, you usually don't have much control over the time and cost corners. In particular, if you're a student doing a team software project in a course, you aren't going to have any control over the time you have to do the project, and you aren't going to have much to say about how many programmers you get to have on your team. The only corner of the Constraint Triangle that you have control over is the quality corner.
The way to economize on the quality corner is not to say, 'Well, I'll write a program with lots of bugs and I won't fix them.' The idea is, rather, to say, 'we're going to strictly limit the number of features that our program will have.'
In limiting features, we need to avoid gold-plating, which is the mistake of accepting overly strong requirements for the program. In addition, we need to avoid feature creep, which is the tendency to keep adding cool new features as the program goes on.