Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

The Pewter Scale, or “How to Maintain Your Balance”

Donald Belcham and I had a conversation today that started “I believe in the iron stool.” I know what you’re thinking, “I’ve had conversations with you. They all start that way.” But the context was different this time.

We were discussing a section of the upcoming book (Google it yourself if you care about it, I feel weird linking to it so shamelessly) that dealt with the iron triangle.image It’s a familiar enough graphic. Time, resources, and functionality are inextricably connected with quality such that you can’t vary any one of them without affecting the quality of your code. Reducing resources, in absence of any other change, will reduce overall quality of the system.

A common (though slightly different) summary of the triangle is: “the software can be on time, on budget, with all the features. Pick two.” This completely ignores quality (or functionality, if you swap “all the features” with “high quality”) but is a nice catchy number to bring out in a meeting to show we’re a self-deprecating kinda crew.

The stool came in from Jeff Atwood’s take. That is, the three components are legs of a stool and quality is the seat. Reduce the time and the quality slides.

As Don and I explored each of these, it became very easy to come up with scenarios where they both broke down. For example, what if we reduce the scope of the project? With the iron triangle, that kind of implies that the quality will drop. The iron stool metaphor implies that if we increase the number of resources on a project, we necessarily have to up the time and the scope in order to maintain quality.

In the end, neither of us had a nice fuzzy feeling talking about it, even though the iron triangle is so well-known in the industry.

But the underlying message is a good one: You can’t look at any of the major factors in isolation. Changing time, scope, resources, or quality all have an effect on the overall project. We talked back and forth about how best to describe the problem. Maybe a square makes more sense? Or a dodecahedron?

The issue we had was in the treatment of the variables. To me, time and resources are inputs, scope and quality are outputs. The inputs are directly related to the outputs but they don’t interact in the same way. Increasing one side means you must increase the other in order to maintain balance.

Once the word “balance” was mentioned, a more appropriate metaphor became obvious. (Well, in fact, the words “balanced” and “unbalanced” were mentioned about five times in rapid succession before someone made the connection. It was actually pretty comical re-reading the conversation.) Namely, a scale. On one side, we have two components: resources and remaining time. On the other, quality and remaining scope.

Here’s the important part. At all times, the scale must remain balanced because each side is precariously perched over a MOLTEN PIT OF LAVA!!! If either side sinks low enough, the entire project goes up in a fiery spectacle that, while entertaining to watch, means at least one person is going down in flames. And we don’t want to see…hmmm…that actually would be pretty funn—no, no, we don’t want that. That would be bad. Failed projects, bad!

With a scale, it is not possible to make a decision about one component in isolation. If you increase the scope, for example, you have to do one (or more) of the following to maintain the balance:

  • Lower the quality
  • Increase resources
  • Increase time

imageSimilarly, if you want to increase the quality, you need to add a corresponding number of resources and/or time. Or drop the scope.

Another important component to this is that you don’t always have direct control over the components. As you near the end of the project, you may determine that you are running out of time. That is, you notice that your remaining time is going down faster than the remaining scope and the scale is starting to list to one side. So you need to make adjustments in order to maintain balance. Ditto if some of your resources start running out the door. At all times, the scale must be monitored to ensure external factors haven’t chipped away at one side of your scale.

There are still plenty of assumptions to be made. For example, not all resources are of equal weight. Simply adding resources to a project, doesn’t imply that quality will automatically go up, or that the project will be done earlier. I’m sure I read somewhere around this interweb that adding more resources near the end of a project can actually be a hindrance rather than a help. Whether or not that’s actually true, it jives with my experience.

But just the same, I like the analogy in general. It appeals to my innate sense of “I’ll never understand unless it’s in metaphor form”.

Kyle the Analogous

This entry was posted in Conscientious Coding. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Bernard Peek

    I used a variation on the theme when I was a project manager. I ask the project owner to put an X in the triangle to show me what their priorities were. That makes it clear that increasing the priority of one factor necessarily reduces the others. I’m now trying to work out how to do the same trick when I have five axes; budget, scope, time, risk and quality.

  • http://codebetter.com/members/WarePhreak/default.aspx WarePhreak

    It seems to me that the triangle works great in the planning stages but the balance is more accurate once the project is under way.

  • http://www.HamishGraham.net Hamish Graham

    Nice! Stumbled across your post by accident, thanks for that – a much better metaphor, I have also had problems trying to understand the iron triangle for the reasons you also mentioned (not making sense for all cases), and was wondering if it was just me… I like your balance metaphor as it does in fact work for every scenario.

  • http://graysmatter.codivation.com Justice~!

    >I’ve never seen a project where the client (internal or external) explicitly states that quality is to measured against maintainability, replace-ability, reversibility or repeatability.

    Oh, they exist. Just depends on the place and the people in charge.

  • http://codewright.blogspot.com/ Kelly French

    Has anyone else worked for someone who didn’t believe in the iron triangle? I have. He wouldn’t accept that trade-offs were unavoidable. He told me to my face that he felt that you could keep your scope and limit time and cost without sacrificing quality. It was a clear sign of delusion.

    I suggest using this on any manager-type, it should be an effective BS-detector.

  • Steve Py

    Yes, long term maintainability is directly driven by code principles. This eludes to what I was referring to being mailny the honus on the development team. This element should always be outside the realm of the triangle/blob. Reasonably clean code should never be more expensive than dirty code so the base principles should never have to be sacrificed based on time/budget/scope. However, many design/architecture decisions around configurability/extensibility are tied directly to scope. Scope should drive the question of whether this application should be easy to extend/alter to suit changing business needs. It’s almost never the client that raises this as a business need, but this should be one of the most important questions business analysts/designers should be asking the client once they’ve established confidence that you can deliver what the they want.

    Sometimes a client will say they only have $125,000 to spend and they’ll accept that any product changes in the future will be more expensive where it might cost $200,000 to design and implement Architecture X around component Y to make it easy to modify & extend as the business requirements change. As long as they understand this up front then sacrificing flexibility on component Y is not a compromise of quality.

    On the same note if I know that a project will cost $125,000 and the client is fixed on $75,000 and fixed on scope, I’ll know it will mean suggesting compromising base principles that I need to deliver a product on time. It’s almost certainly going to go over budget and even if the client does pay for the excess they’re certainly not going to be happy with the end product. Odds are it’s going to cost me money/reputation so I choose to pass on these. (I’ve worked for enough “Vulture-ware” companies to last me a lifetime. :)

  • http://www.igloocoder.com Donald Belcham

    @Steve I can agree that a type of quality is part of the scope of a project. This is the quality that the client asks for which, for the most part, is stated as nothing more than minimal/no/limited defects. I’ve never seen a project where the client (internal or external) explicitly states that quality is to measured against maintainability, replace-ability, reversibility or repeatability. It’s hard to argue that these things aren’t important measures of quality. It’s code principles, such as SOLID, that drive the long term perceived quality of a project (i.e. maintenance costs, speed to add features, etc).

    To isolate quality solely to the implicit functional demands of the client is short sighted in some regards. This is the quality that I see when I look at this equation, triangle, amorphous blob. It’s also this quality that is the first to suffer when resources and/or time are cut, or functionality increases. The code, and it’s future, will suffer from those things but rarely does the defect count.

    Visible (defect) quality and non-visible (code) quality are not always tied together. In fact I’d suggest that most times they’re not. We all know of (or have created) applications that are running fine in production, but the quality of the code precludes the maintenance teams from altering them with confidence or timeliness.

  • Steve Py

    Hmm, well I’d think quality is implied in the triangle. It’s a balancing act between scope, time, and cost and the successfuly output of balancing them correctly is a quality product. The result should be a product that suitably meets the end requirements (feature complete and obviously no show-stopper bugs), on-time, and on-budget. As far as the customer’s concerned, if you can accomplish that you have a quality product.

    The code quality is mainly an honus on the development team’s preference, profesionalism, and discipline. Aside from that I don’t believe it’s separate from scope, it needs to be part of the scope. Software design needs to cater to clients needs, not just their immediate wants. Designers need to ask questions and help define scope to determine if things like extensibility will need to be part of the equation. “Oh yeah, we’d like to be able to take advantage of new technology X in a couple years if it takes off…” etc. The scope includes whether the client wants something that is inexpensive to maintain/enhance, or not.

  • http://www.igloocoder.com Donald Belcham

    @Steve First to your point about teams slacking off. One of the things that we took into account in our discussion was that there are many things such as morale, resource skills, motivation and external forces (other than the client and their needs). It seemed to us that the only way for any of these analogies to work was to fix these factors. All developers have the same skillset (which we know is not true), morale will remain the same throughout the project (again, a falacy) and others like this. If we don’t fix these things, the dynamic nature of projects, people and the world makes the formulation of an analogy far to complicated.

    To your point on reducing on aspect of the triangle affecting quality. The triangle doesn’t even mention quality. This is the point we were trying to overcome. As far as projects managed based on the iron triangle are concerned, quality is not a factor to be considered.

    As Kyle stated quality and scope are on one side of the equation. If I concede to reduce one, the other or both, then I will want to make a reduction in either or both of time and resources. If I don’t make that balancing change, the project is skewed and you either are scheduling to deliver later than necessary or you’re working with too many resources on the team or both.

  • http://www.igloocoder.com Donald Belcham

    @Joe: The logic of the tripod eludes me. If I have 3 legs and two are in fact fixed (say time and scope) I cannot raise the third (resources) leg. With a tripod the highest that a peak can be is equal to the height of the shortest leg. As a result, increasing the length of one leg will create returns only to a certain height.

    I also am unable to see how quality plays into the diagram/analogy then. You state that height depicts equality, but we’ve already ascertained that there is a maximum height and in the case of adding resources, quality would then be limited by either time, scope or both. I don’t see how scope by itself can have that direct of an impact on quality.

  • Steve Py

    I do need to stop reading these first thing in the morning… It was Kyle & Don’s point about reducing scope.

  • Steve Py

    The “pick two” analogy is not about what the project can have, it’s generally what they can expect to fix. (lock in) The client says the scope cannot be reduced and the time cannot be reduced, so resources (cost) must be flexible. If time and resources cannot be reduced then scope must be flexible. This is to maintain a target level of quality. Of course this is within reason. If a team of 6 will take 1 year to complete a project, scope is fixed, and time is fixed at 6 months, 12 developers, or even more may still not be able to meet that deadline.

    Simply reducing one aspect of the triangle doesn’t have to mean sacrificing quality. (as Joe pointed out about reducing scope.)

    Reductions or increases will have an effect on stress, and stress/pressure impacts quality. Increase the scope and leave time/resources the same, the development team feels the need to cut corners to meet the deadline. Increase the scope and resources and you bring in new developers without the time to train them up or be as picky as you should be on their level of experience.

    Whether the pressure of change has an effect on the project depends wholy on the skill and discipline of the development team. Even reducing scope can still have a negative impact on quality. “Good news! The client said they don’t need feature X.” so the undiciplined development team has a collective sigh of relief and figures now they have extra time to spare and slack off until the deadline crunch sets in again. (Or starts “investing” that extra time in extra kitchen sinks that are not needed and probably won’t be fully tested before delivery)

  • Joe

    “As Don and I explored each of these, it became very easy to come up with scenarios where they both broke down. For example, what if we reduce the scope of the project? With the iron triangle, that kind of implies that the quality will drop. The iron stool metaphor implies that if we increase the number of resources on a project, we necessarily have to up the time and the scope in order to maintain quality.”

    Think of it as a tripod, the higher the tripod the better the quality. Extending a leg will raise the apex of the triangle, but with diminishing returns.