Widgets The Iron Triangle and Quality

The Iron Triangle and Quality

By Nick at August 16, 2011 02:28
Filed Under: Software Development

More from my Embarcadero Blog.....

Another great article called "The Iron Stool" by Jeff Atwood, and on a topic near and dear to my heart these days.

I talk a lot about quality when I’m on the road and visiting with customers.  I consider the quality of the product to be the #1 feature going forward.  When I talk about "quality", I’m talking about speed, performance, and stability all wrapped up into one thing.  I know that no matter what the feature set for a given release, if the perception is that the product lacks quality, it will not be as well received as it might otherwise have been.  You all have been very clear that quality is important, and we are taking that very seriously.

Jeff’s article talks about the classic "Iron Triangle"of Time, Resources, and Features and how they interact to limit what you can do on any given software project.  Increase one, and the other two are affected.  Decrease Time, and you get fewer features.  Increase Resources and you get more features.  It’s a constant tug and pull between the sides of the triangle.  You have to keep the triangle balanced.  You can’t pad up features without adding in more resources or more time.

Well, actually, you can, right?  You can add features to a project, without increasing time or resources.  But of course, when you do, something else has to give, and that something is quality.  Give people a fixed feature set, limited resources, and a set date to finish, and you’ll probably get the product — but at the cost of that quality of the thing delivered (assuming that the time constraint is limted, of course).

Jeff then point’s out a co-workers analogy that it can be compared to a three-legged stool.  It took me while to figure out what she meant, but I stewed on it a while until I realized that if you shorten one or two of the legs of the stool, the "quality" of your sitting experience will be less than perfect.  To maintain a good sitting experience, you have to keep all three legs balanced.

But I don’t agree entirely with that analogy, because if you expand time, (that is, increase the amount of time allotted to complete the features even with fixed resources), you’ll get more quality.  Increased time is the one thing that should almost always improve quality.

One of the commenters to the post pointed out that some people view Quality as the area of the triangle. Pull on the corner of any triangle, and it’s area will increase.  Push on it and it’s area will decrease.  But that breaks down because adding more features will not help quality – doing so just creates more things to break and less time used up to test for and fix bugs.  Adding resources or time to a project will increase it’s quality, as long as the resources are added a the beginning.  Time can be added, well, any time.  ;-)

Another way to think about it is to make the three sides be Time, Quality, and Features.    Much of the time, resources are relatively fixed. That is the way we operate here — we have a team of developers, the size of which changes only marginally.  Brooks Law states that you should be less inclined to increase a team’s size the farther along the project is.  Since resources should only be altered very early in a project, Resources are to a large degree not a variable entity in the equation.  Features and Time are variables that can be adjusted much more easily along the way.

So it’ isn’t entirely clear how the "Iron Triangle" analogy holds.  I do know this — spend more time on quality and you’ll get quality.  And that is what we plan on doing for the Highlander release.

blog comments powered by Disqus

My Book

A Pithy Quote for You

"Luck is what happens when preparation meets opportunity."    –  Seneca

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.