Kevin P. Taylor

Quality, the Four Variables' Stepchild

We've all heard of the four variables (a version of the Iron Triangle) that comprise the inputs of a software project (or any project, for that matter).

1. Time: The calendar time required to complete the project, i.e., the completion date.
2. Resources: The cost of the project in scarce resources, such as salaries, tools, data center space, or bandwidth.
3. Scope: The value to be delivered. In software, this is typically measured in business value via story points, features, or a similar measuring unit.
4. Quality: How well the scope is delivered.

Arguably, the most controversial and difficult to define of the four variables is quality. 

Some people believe quality and scope cannot be separated. They believe that scrimping on quality is just an underhanded way of reducing scope. Others believe that quality is not a variable at all. These folks would argue that the quality of the output of a particular team is a given, not a variable. Others even believe that quality is an absolute. Quality must always be at 100%. But, 100% of what?

I tend to think of quality as the professional practices of the development team. How rigorously do they follow good (XP) development practices? Are they pair programming and testing first? Are they using continuous integration? Are they designing maintainable software using techniques such as the open-closed principle and refactoring?

If defined in this way, quality can be a useful variable. For instance, a team may choose to do without pair programming during an iteration  in order to increase scope. Or, they may choose to delay particular refactorings until a later date (or forever). Or, a startup may have limited financial runway and simply will not takeoff without massively reduced quality. How many successful products, such as Microsoft's Office or Amazon.com would not exist today if they hadn't scrimped on quality early on in order to get to that first revenue producing stage.

Is reducing quality always the right or wrong approach? It usually will be the wrong approach just as would be paying your mortgage on a credit card. Eventually, most reduced quality must be repaid with interest. 

But, by evaluating potential project input decisions within the framework of the four variables, you can make tradeoffs intentionally and increase the chance a challenged project will be considered a success by the stakeholders.

7th Grade Hackerpreneurs

I had fun reading this Chicago Maroon article. It reports on two seventh-grade hackerpreneurs who recently developed and launched an iPhone application called The Mathmaster (iTunes link). According to the report, the two spent spring break away from their elite University of Chicago Lab School hacking code and creating a new enterprise.

Now, sure, their fledgling enterprise may only be generating a few 99 cent downloads each day. But, viewed in terms of revenue per day of experience of the founders, these kids are doing pretty well and are already on their way to achieving their 10,000 hours. (Malcolm Gladwell claims that approximately 10,000 hours of effort are required to achieve mastery in a given pursuit.)