The project triangle says that the quality of a project is determined by three factors: Cost, Scope, and Time. We can choose two of them, but not all. There are three possible combinations:

• Choose Cost, Scope, and Time (or Quality) will be impacted
• Choose Cost, Time, and Scope (or Quality) will be impacted
• Choose Scope, Time, and Cost (or Quality) will be impacted

In a concrete example, let’s pretend that certain features of a project (Scope) are planned to be completed in two months (Time) by two engineers (Cost).

If, due to business changes, the project needs to be completed in one month by one engineer, the options are to either reduce the scope, or lower the quality of our product (but don’t do this, please keep reading).

Quality

When we speak about quality in software development, it’s not only about whether the final product works or not, but also about how it was built.

A high quality product is something that can pass the test of time. New features can be added without major refactoring, and its very few bugs can be easily debugged and fixed.

In contrast, a low-quality product will be hard to update to meet new demands; or it may have lots of bugs that are either hard to root-cause or resolve.

The Impact on Quality

Sometimes, people managing a project will try to control Cost, Scope and Time, all at the same time while expecting that we keep the same quality.

This is usually because they have goals that relate to metrics such as lowering costs or delivering more products per quarter. These things mean reducing headcount, reducing projects’ timelines, and increasing scope.

I’ve seen this happening many times, even by people who have been developers themselves. This is sometimes intrinsic to the role, and it’s really difficult to avoid the pressure. Sometimes they don’t even realise that they are falling in this trap.

So, instead of judging, there is one thing that we must do as software developers. Stand our ground on quality.

Standing Our Ground

Just like other people are responsible for team delivery, we are responsible for the quality of our code. We know about code, and we can give the best recommendations. We are hired to tell the business what we have to do from the technical perspective.

Because of all those reasons, we cannot accept lowering the quality of our products. We know what are the long term consequences to the business if we accept this, so we must stand our ground firm on this point.

We cannot decide what feature to build. We cannot decide how much time we have to deliver. We cannot decide how many people will work on a project. But we must decide the quality of the product, and the quality should be high.

Robert C. Martin makes a very good analogy. Imagine a hospital that wants to do more surgeries per day. To achieve this, they instruct surgeons not to wash their hands, and that instruments will not be sterilised. I can’t imagine a single surgeon that would accept those conditions.

The same happens in software projects. We cannot accept working in a project where processes and standards that drive the product Quality are skipped. We, as the surgeons, must stay firm in our principles that quality cannot be affected by any business decisions.

Estimates

Unlike construction or other physical projects, software projects cannot be easily estimated. Many people have tried and failed at accurately estimating the time to complete a project.

However, estimations are still very valuable to software projects, as long as it’s clear that they are estimates, educated guesses, nothing more. They are not blood oaths or commitments.

For example, once my team was asked to complete a specific project in one month. We considered every possible variable, and based on our knowledge and experience, we estimated that it was impossible to deliver the required scope in the required timeframe (even with more people, due to the onboarding time). There’s a light chance that we could have done it and our estimate was wrong, but that was a risky move. The company understood that, and decided to follow our advice.

Estimates become a problem when they are considered commitments. When a project gets delayed, stakeholders or managers may demand that we keep “our word” and deliver in time. Or, worse, developers may unconsciously feel that they’re not delivering on their “promise”, and either do extra hours or rush some code at the expense of quality. In either case, the problem is not the estimate, but a feeling that we’re not delivering on a commitment.

Estimates give valuable information about a project so we can consider adding more people (increase cost) or deliver fewer features (reduce scope), while keeping the same quality.

I have worked in many successful projects. They have been successful not because we have delivered them as originally planned, but because we have been able to adjust the timelines, developers and/or scope so we can still deliver a valuable product, without impacting quality.

Happy testing!
José Miguel

Share if you find this content useful, and Follow me on LinkedIn to be notified of new articles.