complexity

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 →

6 Strategies to Simplify Software

How do you make things simple?

I’ve written that simplicity is powerful, and that it undergirds many deep architectural breakthroughs. In posts about pragmatism and balance, I’ve quoted Oliver Wendell Holmes about the simplicity on the other side of complexity.

But I’ve never talked about how to achieve it.

photo credit: hurley gurley (Flickr)

This is not an easy question; if we knew how to make things simple, we’d do it more often and more quickly. It takes some serious effort (and genius) to go from centuries of experiments and volumes of equations to e = mc2. I’ve been pondering simplicity in software architecture for a decade, and I’m certain I’ve only scratched the surface.

Still, simplicity is a learnable skill, and some strategies are consistently helpful… Continue reading →

The Power of Simplicity

Most stories about zen masters, gurus, or other paragons of wisdom follow a similar pattern. The pupil discovers a problem. He or she struggles with it. The problem gets more and more overwhelming. Solutions are elusive. Finally the pupil goes to the master and pours out his heart, whereupon the master offers a pearl of insight that radically reinterprets the problem.

Seek the simple... Photo credit: departing(YYZ) (Flickr)

Seek the simple… Photo credit: departing(YYZ) (Flickr)

There’s a reason why this narrative exists in every culture: human beings need the insight that comes from synthesis, pared down to its essence. We crave the simple but profound:

  • Less is more.
  • Do unto others as you’d have others do unto you.
  • A watched pot never boils.
  • Freedom isn’t free.

The software industry desperately needs this sort of insight, but far too often I see us operate in the stage of the narrative where the pupil misunderstands the problem, struggles, and makes things worse. Continue reading →

Why

Recently I’ve been digesting Start With Why, by Simon Sinek (Another nice find, Trev!) For an overview, watch his TED talk.

Maslow’s hierarchy of needs. A person’s “why” can derive from any of these levels, but I think I’ll be happiest if I can map mine to the top of the pyramid.

I don’t buy everything in the book, and I think many of the author’s assertions would be stronger if he offered detailed evidence. For example, he asserts that Apple is special because it has a driving “why” that shapes company decisions in fundamental and pervasive ways, and glosses over how Apple lost its vision during the non-Steve-Jobs years.

Why “why”?

Nonetheless, his central premise is insightful and important: starting with “why” we do things will create greater satisfaction, wisdom, and success. Once we have a why that’s correct in our hearts, many of the whats and hows of life flow naturally. Sacrifice, patience, and creativity blossom. This is true of our software architectures, product requirements, general business activities, personal relationships, and other endeavors. People who hate their jobs often feel that way because they find their days filled with activities that they deem empty or soulless. Human beings can’t be passionate about stuff that doesn’t resonate with their deep values to some degree.

I find interesting resonance between Sinek’s thesis and other important ideas such as Jim Collins’ hedgehog concept, the idea of laddering in marketing theory, Maslow’s hierarchy of needs, and Covey’s “begin with the end in mind.” I also find it interesting how congruent this is with a central tenet of Bridging the Communication Gap, by Godjko Adzic; he argues that the “why” of a product requirement, rather than the “what”, is the most important thing for product management to articulate. (Thanks, Shawn, for the great book recommendation.)

My Why

Which leads me to this: I need to articulate and then be true to my own “why.” Why, exactly, am I in the software industry? What do I hope to accomplish? Why do I work on enterprise software, as opposed to mobile apps or cool web mashups? Why did I start a blog? Why do I pick certain topics for my posts, and then spend significant time articulating my thoughts?

Here’s my current answer:

I believe in making complex computing simple so the world can innovate and improve.

Testing My Answer

What I like about this answer is that it ties back to my core values. I believe we have opportunities to do lots of good in the world–eradicating poverty and disease, advancing science, learning to understand and value one another better. And I believe an impediment to that is all the complexity we create and discover. Big data is hiding a lot of the insight that would let companies serve customers better. Number crunching supercomputers are needed to predict the weather better, to help predict crop yields in Bangladesh. And so on.

Thus, if I can do my part to make really tough computing problems more tractable, I’m helping make the world a better place.

I also like that this answer tells me when I’m wandering. If I’m building systems that don’t hide/manage/solve complexity, I’m probably off track. If I am building software that’s frivolous (“Angry Birds” comes to mind), I probably won’t be very happy. If I work for a company that aspires to nothing more grandiose than making money, I should either change the company or change my job. If my blog posts don’t help me understand or communicate on topics that reinforce that goal, I’m wasting my time.

Challenge

What is your “why”? Struggle with it until you come up with a satisfying answer. Then use it to test your current work assignments. Does this exercise give you any insight or point to ways to rebalance your priorities?

Related articles

Don’t forget the circuit breakers

Recently I’ve been pondering an interesting book called Release It!, by Michael Nygard. It’s full of anecdotes from someone who has spent a major portion of his career troubleshooting high-profile crashes of some of the most complex production software systems in the world–airline reservations, financial institutions, leading online retailers, and so forth.

circuit breaker

A circuit breaker. Photo credit: Wikimedia Commons.

One design pattern that Nygard recommends was new to me, but it rang true as soon as I saw its description. Like many classic patterns, I’ve implemented variations on it without knowing the terminology. I like Nygard’s formulation, so I thought I’d summarize it here; as I’ve said before, good code plans for problems.

The pattern is called circuit breaker, and its purpose is to prevent runaway failures.

In systems without circuit breakers, failures in an external call may cause an exception on the caller’s side; this can cause the caller to log, retry, and/or execute other specialized logic. Since errors are supposed to be the corner case, the blocks of code that handle them are often expensive to execute. The very slowness of the error-handling codepath can be the source of further failures, because locks are held longer than normal, or because we poll until a connection is restored, overwhelming a system that’s already limping.

Or, to borrow an old idiom, “it never rains but it pours.”

In the circuit breaker pattern, on the other hand, the caller assigns each “circuit” (a codepath that invokes an external entity) to one of three possible states: closed, open, or half-open. Continue reading →