The Iron Triangle is a common way to refer to the different aspects of a software development project. In his great article, The "Broken Iron Triangle" Software Development Anti-Pattern, Scott Ambler states that "...something has to give, whether you want it to or not". We all know this is true. If you have fixed schedule and fixed budget, the scope of the project has to be flexible for the other two criteria to be met and the project to have any chance at succeeding. The one thing that Scott's article doesn't discuss in any great detail is the Quality aspect.
The longer I practice in this profession, the more that I think about the long term quality of the application's code base. In my mind quality comes in two forms. The first is the quality that the client defines as a non-functional requirement. For example, there must be no reported and outstanding defects for the application to be released to production. Usually the client will define quality in a way that is based on acceptance of the applications functionality in a working state. The most common measure of that is defects. The second type of quality is the the one I mentioned at the start of this paragraph; long term quality. Rarely does the client explicitly define this type of quality. It will include things like the maintainability of the code base, the ability for new feature to be added, existing ones to be altered. Really this is all about '-abilities'...maintainability, reversibility, replaceability, repeatability, etc.
If you look at the Iron Triangle the Quality portion of the project is, if included, usually placed in the center of the triangle. It doesn't really fit into the analogy all that well. Today Kyle and I were hashing out what the Iron Triangle meant to us in terms of software development. Neither of us could rationalize the exclusion of both written and visual representations of quality. After a long IM chat that went in circles, triangles and at one point a dodecahedron (don't ask). Our final point in the conversation ended not on a shape, but instead on a balance scale.
The point we ended on is that there are four components and 2 reside on each side of the scale. On one side are Schedule and Budget. On the other side are Scope and Quality. We always want our project scale to remain balance and to do that it's all about give and take. Think of each of the four items as weights on the balance trays. With that in mind, here are some of the common scenarios.
The client increases the Scope of the project.
To keep maintain the balance you can have four options:
- Increase the Schedule
- Increase the Budget
- Increase both the Schedule and the Budget
- Reduce the Quality
The client reduces the Schedule.
- Decrease the Scope
- Decrease the Quality
- Decrease both the Scope and the Quality
- Increase the Budget
The client decreases the Budget.
- Decrease the Scope
- Decrease the Quality
- Decrease both the Scope and the Quality
- Increase the Schedule
There are ways to make this pattern break. For example, increasing Budget often equates to adding developers. As is stated in the Mythical Man Month, this is not practical without incurring a decrease in productivity. Also, not all developers are created equal. Adding a poor developer, even early in a project, can often be more of a impediment to than benefit. As a result our conversation decided that, while important and facts of life, the simplicity of any model (including ours or the Iron Triangle) requires that all needed to be qualified with the statement "...all things being equal".
Thoughts?
posted @ Tuesday, February 24, 2009 7:34 PM