2 Surprising Truths About The Iron Triangle

Project management 101 teaches that, when managing outcomes, you cannot alter scope, schedule, or cost (resources) without affecting at least one of the other dimensions. This interrelationship is known colloquially as the “Iron Triangle.” Sometimes we put “quality” in the middle to show how it is unavoidably shaped by choices on the other constraints:

Image credit: John M. Kennedy T (Wikimedia Commons)

Lots of Dilbert cartoons derive their humor from the unwillingness of the Pointy Haired Boss (PHB) to acknowledge this relationship. These cartoons are funny because they are so eerily similar to conversations we’ve all had, where someone wants us to deliver ultra-high quality, on a limited budget, in an aggressive timeframe, with a boatload of features.

It ain’t gonna happen, folks. We engineers are clever, but we’re not magicians. Triangles don’t work that way.

You’ve learned some good principles when you can articulate this geometry lesson.

But there’s more.

Truth 1: Scope is a trickster

Many well meaning managers and executives understand this trilemma, and they distance themselves from Dilbert’s PHB by acknowledging that something has to give. “I pick scope,” they’ll say. “We absolutely must have the product before the summer doldrums, and we only have X dollars to spend, but I’m willing to sacrifice a few features.”

This can give product management heartburn–feature sets sometimes hang together in ways that make slicing and dicing dangerous. An airplane that’s good at takeoffs but that can’t land is unlikely to be a commercial success. Good product managers will point this out, and they’ll be right.

Continue reading

Good Code Is Optimized

(Another post in my “What is ‘Good Code’?” series…)

Yes, optimized.

But for what?

A lot of programmers seem to think that raw speed of execution is the only possible answer. If pushed, they may admit it’s also possible to optimize for minimal memory usage or minimal size of executable. Compilers have switches for that.

Get out of the box. Photo credit: lel4nd (Flickr).

Emerson said, “A foolish consistency is the hobgoblin of little minds.” In modern terms, he was deploring the lazy instinct to accept established wisdom instead of thinking outside the box. And I think optimization is one of those topics where we need a larger vision.

What about optimizing for:

  • Speed of coding (sometimes programmer time is the most constrained resource…)?
  • Ease of use (often, low learning curve and productive users outweighs all other factors…)?
  • Speed of testing (sometimes provably correct is the most important success criterion…)?
  • Full utilization (the major promise of physical-to-virtual-to-cloud migration)?
  • Ease of understanding and maintenance?
  • Integration with external systems?

Selecting the criteria against which you optimize is more than a technical question. It’s a strategic one, driven by business and organizational goals. Programmers who relentlessly pursue speed of execution to the exclusion of other considerations are not doing their teams or their companies a favor.

Action Item

Optimize one function for ease of understanding and maintenance. Make a short list of how your choices were different than they might have been if you optimized for speed of execution.

Good Code Is Balanced

In my first post about what constitutes “good code,” I claimed we were dealing with a complex question. This is why I distrust short answers.

So many competing concerns must be balanced to achieve goodness:

  • Testability
  • Maintainability
  • Short-term revenue pressures
  • Long-term strategic value
  • Performance (many aspects)
  • Scalability (up, down, across)
  • Ease of use
  • Supportability
  • Conceptual integrity
  • Alignment with the skills, temperament, interests, and tools of the team that owns it
  • Cost vs. benefit (for some problems, quick and dirty is definitely “right”)
  • Simplicity (separation of concerns)

More items undoubtedly belong on the list. Quite a balancing act!

Someone’s got this “balance” thing down! Photo credit: joãokẽdal (Flickr).

Action Item

Pick a module, application, or subsystem that you know well, and grade its code according to how much its coders emphasize a few different dimensions (e.g., performance, testability, scalability, ease of use). Do you like the balance? Are any attributes being neglected?