DEVOPSdigest

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 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.

Other additions to the triangle: The Project Management Body of Knowledge (PMBOK) added risk to the triangle – helping to expand it to a six-pointed star. Risk, however, is more than a project constraint, as there are many types of risk. In addition to the risk of violating any individual constraint, there are also systemic risks like opening a security hole or violating a regulation. Adding risk, therefore, muddies the purpose of the triangle.

The Agile world also contributed a variation of the triangle with Jim Highsmith's Agile Triangle. Highsmith collapsed all the constraints into a single vertex, and differentiated value from quality to populate the other two corners. Quality, according to Highsmith, represents the current quality of the project while value represents “future quality – ‘can the product continue to deliver value in the future?',” according to Highsmith. He explains: “responding to the unanticipated future requires adaptability, and the key to adaptability is keeping technical debt low.” In other words, software value depends upon its adaptability, and adaptability depends upon lowering technical debt.

Highsmith makes some important points, but by collapsing the traditional Iron Triangle constraints, he doesn't provide a clear explanation for how to balance quality, value, scope, cost, and time – and now with added implicit constraints of adaptability and technical debt, the resulting model isn't all that useful. There is also widespread confusion about the challenges of both inherent flexibility and “good” technical debt (be sure to read my discussion of technical debt, if you haven't already).

Remember that Hightower ties inherent flexibility to value – a critical connection for any Agilist to remember. However, he inadequately addresses the connection between adaptability and technical debt, jumping to the conclusion that keeping technical debt low is always a good thing. In fact, careful and temporary acquisition of technical debt, just like the careful borrowing of money that generated the metaphor – is in reality an essential part of Agile development.

In my 2013 book The Agile Architecture Revolution, I took a different, but similar approach to extending the Iron Triangle by adding agility to the mix as an explicit constraint, turning the triangle into the Agile Architecture (AA) Quality Star below.

The Agile Architecture Quality Star

In the figure above, the traditional Iron Triangle continues to represent the scope/cost/time tradeoff, while an additional triangle – the agility/quality/time Best Effort Triangle – represents a separate tradeoff: the more time you devote to quality, the less agile you become. The point to the AA Quality Star is to elevate agility to the status of a metarequirement and thus a constraint to the project, which in turn requires us to rethink how we deal with quality when agility is a priority.

Beyond The Agile Architecture Quality Star

While Highsmith's value constraint and my agility constraint both recognize that the ability for software to be inherently flexible – that is, the ability to respond to future requirements as well as current ones – is an important added constraint to any software that claims to be Agile, neither of us fully explored the fact that inherent flexibility and resilience are actually two separate constraints. Inherent flexibility supports an organization's desire to be more innovative and responsive, which are two of the three elements of business agility. The third element is resilience: the ability to recover from adverse events.

In the past, we typically took a brute force approach to building resilience into our software by hammering on it until it passed its performance tests and then hoping it wouldn't break in production. Today, however, we have a deeper understanding of resilience, as cloud computing has forced us to rethink how we deal with failure. It's no longer adequate to build software with the goal of preventing failure. Rather, we must build software that automatically recovers from failure. Expecting and planning for failure, including the graceful degradation of functionality should faults develop – what we might call Chaos Monkey Engineering – is an essential part of building software that supports the business agility driver.

Read The DevOps Drumbeat - Part 2

Jason Bloomberg is President of Intellyx.