Triangles have been a staple of mathematics, architecture and engineering for centuries. They have also become important in software development by way of a project management concept. You may have heard of the “Fast/Good/Cheap” rule. This rule uses a triangle to depict and constrain the attributes of a project that are usually in conflict during development: schedule, quality and budget. Ideally, a project should maximize speed (Fast), quality (Good), and efficiency (Cheap).

The rule of “Fast/Good/Cheap” states that a customer can choose only two of these attributes to maximize. The third, unchosen attribute, will naturally suffer. This is a physical constraint of a triangle, and a realistic constraint of a project.

If you consider the area of a triangle to be constant and represent the scope, or requirements of your software project, you can create numerous triangles to model the “Fast/Good/Cheap” rule. For example:

Remember, the area of the triangle (scope of the project) must remain constant. Therefore, a change to any one side of the triangle necessarily affects the other two. The implications are these:

• Good & Fast = Expensive. High quality software will be produced very quickly to meet a customer’s time constraint. However, this approach will require additional staff, extended work hours, additional testing, etc. — all things that will drive up the cost of the project.
• Good & Cheap = Slow. High quality software will be produced; however the project tempo will be slow. Other projects will take priority over this project and interrupt its schedule frequently.
• Fast & Cheap = Poor Quality. The project will be done quickly and on a shoe string budget, and you will get what you pay for. Don’t expect all of the requirements to be met and expect some bugs and unpredictable behavior because the development team didn’t have the time or resources to thoroughly design or test the software.

In reality, everyone wants Good & Fast, but can’t afford it so they settle for Fast & Cheap. Then one of two things happen:

1.  Inferior, non-compliant, buggy software is delivered that the customer is unhappy with and your company gets a bad reputation for poor quality.
2. You and your staff absorb all the cost and overtime required to produce quality software on an unrealistic schedule with an insufficient budget (because you are perfectionists). You are lauded as heroes, but the project actually cost you money instead of making you money.

Ideally, you strive to strike a balance among these competing constraints, although some projects will justifiably favor one attribute over another.

All complex systems are difficult to model, and the software development process is no exception. This very simple model can be used to easily and quickly demonstrate to customers how changes to any of a project’s constraints (Fast/Good/Cheap) will effect the other constraints of the project. I have used this model numerous times to demonstrate how these constraints relate and the consequences of changing or over emphasizing one of them. A picture is worth a thousand words and customers usually get the “Fast/Good/Cheap” rule immediately once you draw the triangle. And best of all, beyond its obviousness, there is a lot of solid project management research and data to validate it. I will leave that reading to you.