Month: July 2013

Convoys as a model for distributed architectures

It occurred to me this past week that convoys–especially the kind where truckers form and manage ad hoc communities through chatter on CB radio–are an excellent model for the sort of distributed software architecture that cloud-native software demands. In part 2 of my series of posts about how to “cloudify” your code and designs on Adaptive Computing’s website, I discuss the lessons that programmers ought to absorb from their role models in big rigs. Head over there and check it out.

Convoys require frequent, real-time, adaptive coordination by many independent actors. Photo credit: Sangudo (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.

Features are not chunks of code

Before the industrial age, “features” were noteworthy aspects of a face or a geography: a patch of color, abundant wrinkles, a scar… The human brain is stunningly good at identifying and comparing such features–perhaps because that ability has been central to our nurture as children, our bonding into family units, and our survival as a species.

danie-franco-o1PKM7-8AH4-unsplash

Photo by Danie Franco on Unsplash

When we want to say what a face looks like, we describe its features. They are an entrée into experience with it.

At the dawn of the computer age, the advertising and publishing industries were already talking about how products–or aspects of them–could be “featured” in media. Highlighted characteristics were called “features”, and this metaphor transferred seamlessly into digital language. Software product managers now traffic in “features” and “feature sets.”

We use the term so comfortably that we sometimes forget what it has to teach us.

Continue reading →

Programmers: learn how to “cloudify”

The blogosphere has plenty to say about cloud computing, but most content targets the business, CIO, or IT crowds. Information exists for developers who want to produce software friendly to cloud computing, but it’s more scattered, it’s vendor-centric, and it doesn’t match the SEO profile that obsesses much of the industry. As a result, I believe that many developers have only hazy ideas about how they can leverage the power of the cloud to provide radical improvements in scale, responsiveness, and connectivity for their customers.

This ought to change. Cloud computing isn’t just interesting to datacenter managers; it enables many new technological strategies. Cloud-savvy engineering can boldly go where no software has gone before—if we’re smart enough to take it there.

Clouds on the horizon… Photo credit: fir0002 | flagstaffotos.com.au

On my company’s website, I’ve begun a new series of blog posts about how to “cloudify” your code and designs. Read the inaugural post, and check back on Fridays for new installments in the series. I’ll be making connections back to concepts here on codecraft, such as what the programming language of the future ought to look like, how to encapsulate for cloud, and so forth.

I believe that a competence with cloud–cloud-oriented programming, if you will–will be a checkbox on future tech resumes.

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 →