Most software has a profoundly inadequate concept of “health.” In order for applications to run, they must:
- have adequate resources (RAM, disk, network, CPU)
- receive cooperation from services exposed by the operating system or by network endpoints
- be adequately and correctly configured
- not be hacked
- acquire delegated privileges from users
… and so forth. And yet, most software that I’ve encountered in my career does little to see whether it’s working properly and has what it needs. Sure, it may log a catastrophic error if the disk fills up, but it makes no effort to see the problem coming or to plan more graceful recovery than a crash.
In my most recent post on cloudifying your software, I explore how cloud computing is magnifying the need to understand and to regularly check your software’s vital signs. Head on over to adaptivecomputing.com/blog and check it out.
Checking vitals isn’t just for healthcare… Photo credit: U.S. Pacific Fleet (Flickr)
Stay tuned for further installments of this series each Friday. As I said in Part 1, I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.
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.
Friday morning I was at a seminar taught by Jason Taylor, CTO at Allegiance. We were discussing how dev team velocity and product quality can compete for our attention; sometimes we trade one for the other. Jason mentioned that he’s a fan of competing metrics, and some neurons connected in my brain.
Plumb line suspended from the center point of multiple balancing legs. Photo credit: suttonhoo (Flickr)
I’m a big believer in measurement. As the old adage goes, you can’t improve what you don’t measure. Next time someone urges you to change a behavior, or tells you she’s going to, ask what measurement of change is being proposed. If you get an unsatisfying answer, I predict you’ll also get an unsatisfying outcome.
I’m also a big believer in balance, as I’ve written about before. Good software balances many considerations.
Besides these existing predispositions, I’d recently read a blog post by Seth Godin, cautioning about the need to choose wisely what we measure. And I’ve been digesting The Fifth Discipline, by Peter Senge, which advocates wholistic, systemic thinking, where we recognize interrelationships that go well beyond simplistic, direct cause-and-effect.
All of these mental ingredients Continue reading