What it means to build quality software has taken a beating over the years. We’re no longer content to strive for defect-free code. We must also make sure the software meets both its functional and nonfunctional requirements. Only now with the rise of more Agile ways of thinking, we’ve placed the notion of a software requirement under the microscope, as building flexible, resilient software often trumps checking items off our requirements list.
As a result, the tried and true Project Management Iron Triangle (link is external) has taken its lumps. We’ve been trying to bend or rework the Iron Triangle for years, with limited success. Today, thanks to DevOps and Agile Architecture, we finally can.
Adding Corners to the Iron Triangle
You remember the Iron Triangle: vertices at scope, cost, and time. Any project might fix two, but the third must be allowed to vary. Inadvertently fix all three? Then quality suffers – an unacceptable result.
The Iron Triangle
We’ve tried adding quality to the triangle over the years to let us fix the other three constraints, turning it into the Project Diamond, but that move was a rather academic exercise. After all, you can’t go to your boss and say “we delivered on all the requirements on time and on budget, but sorry, it just doesn’t work!” People insisted on taking quality as a given, and lived with the triangle as-is.
Read the entire article at http://devopsdigest.com/the-devops-drumbeat-part-1.
