Month: January 2013

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

Book Review: Universal Principles of Design

A few months back, my friend Trev recommended this book to me. I’ve been digesting it one topic at a time, on my lunch breaks.

It is profound and fascinating reading.

This is not another software pattern book. In fact, it is not really software-centric at all. It describes truths about the way human beings perceive, reason, generalize, and communicate. Many of them have obvious application to UX, UI design, and to software in general. On the scale of profundity, it gets a 9 out of 10; I suspect that I’ll be blogging about insights from the book for months to come.

I think it’s important to look at familiar problems from new angles; many profound breakthroughs in science are attributable to cross-disciplinary insight. Though time spent in this book won’t directly hone your coding skills, it will help you see recurring problems and solutions with new eyes, and it will suggest tried-and-true criteria for evaluating design alternatives.

As a teaser, some of my favorite design principles in the book include: Interference Effects, Contour Bias, Horror Vacui, Uncanny Valley, Recognition Over Recall, Wabi Sabi, Satisficing, and Propositional Density.

For now, I’ll omit any definition of what these intriguing terms mean, and leave discovery as an exercise for the reader. :-)

Related articles

Interrupting my interruptions

Tonight I was just settling down for a ponder on some personal stuff when I noticed an email from my brilliant brother-in-law (hi, Stephen!), recommending an article about the cost of interrupting programmers. Half an hour later, I’m blogging about it. Yes, I see the irony in the read, the blog, and the shout-out, but I just can’t help it.

I’ve heard lots of estimates of the cost of interrupting, but the research in this article seems particularly clear. I think the article oversimplifies by assuming that the problem and solution derive purely from memory, but there’s enough insight and clever thinking in the article to make it worth a read…

We’ve all known that interruption = bad. We’ve nodded our heads at this wisdom for years. Occasionally we give lip service to it. We try to clump meetings in one portion of the day, leaving blocks of time for serious thinking and work. We advise our teams to use “lighter” interruptions (“ask your question by chat/email instead of in person; it’s less disruptive…”). We decline non-essential meetings and urge others to keep their invite lists small. We buy “cones of silence” and “Do Not Disturb” signs and set them up outside the cube of the guy who’s trying to finish urgent work for an impending release.

And then we fall off the bandwagon.

At least, I do.

Hi. My name is Daniel, and I’m addicted to interruptions. :-)

time_management

Image Credit: xkcd

Symptoms

You would see my addiction if you walked past my desk and looked at the tabs in my browser: two for email (work, personal), two or three for calendaring, some chat sessions, a task list, several programming topics, a man page, a python reference, an interesting blog post or two, three wikipedia pages, a ticket I looked up before I ran to my last meeting, a wiki page I’m in the middle of editing, a competitor’s product portfolio, a LinkedIn discussion forum on cloud computing, a Google spreadsheet, the PDF of a resume I’m supposed have read before I do an interview in an hour, half a dozen random sites that I visit during the day as I check gossip on a competitor or read the Dilbert cartoon someone emailed me…

How am I supposed to think Deep Thoughts when I’ve got that much noise?

Continue reading →

Earned Pragmatism

The other day I was on Gene Hughson’s blog (he’s a smart guy, btw; I recommend a visit), and I noticed a badge that said that he had signed “The Oath of Non-Allegiance.”

That piqued my curiosity.

I followed Gene’s link and ended up on Alistair Cockburn’s website. Alistair is one of the early torchbearers for the agile software movement. I’ve written previously about signing the Agile manifesto, so I felt like I was swimming in friendly waters.

The oath is about being open-minded and pragmatic:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

In other words, let’s examine ideas on their merit, rather than dismissing them because they don’t align with the programming or process or architecture or platform buzzword du jour.

I signed. Good stuff.

However, the oath got me thinking a bit, and I want to register two notes of caution.

Caution 1: It is possible to be too pragmatic.

On the continuum that has “ivory-tower idealism” at one end, and “pragmatism” at the other, I’m well past center, favoring the pragmatic side. However, we should not discount the value of idealism. It was pragmatists who found enough compromise to ratify a constitution that made a loose confederacy into the United States of America–but it was the firebrand idealism of folks like Thomas Paine that articulated a vision, inspired a previously fragmented public, and provided the heat to carry the revolution through its darkest winters.

You need both.

I have seen architects that are way too ivory-tower. They make recommendations based on their favorite patterns and methodologies, with little regard for practical consequences. Smart engineers quickly dismiss them as being out of touch and irrelevant, and they are right to do so.

On the other hand, I have seen “architects” who, despite deep talent as engineers, are forever in the mode of “whatever gets the job done” and “if it ain’t broke, don’t fix it.” I believe this view is short-sighted; it loses touch with the opportunity cost of sub-optimal decisions, and with the human passion that keeps architectures healthy. Codebases owned by this type of “architect” tend to be rife with tech debt, with no roadmap or process to haul the team up and out. Where there is no vision, the people perish.

Caution 2: Pragmatism must be earned.

Before you can be a pragmatist, you have to understand what’s possible, what’s good and bad about each alternative, and why certain considerations might trump others given a certain business context and time horizon. This perspective doesn’t come cheap; it’s been my experience that only the school of hard knocks teaches these classes, and the tuition is expensive.

I mistrust anyone who lightly dismisses OO or message passing or actors or whatever the technique is, on the basis of shallow prejudice–but I also mistrust anyone who picks and chooses from the smorgasbord based purely on convenience of the moment. As Oliver Wendell Holmes said, “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.” Unless you truly wrestle with the complexity, pragmatism can degenerate into cheating and chaos. Or said another way: only seasoned idealists earn the right to be pragmatists.

Action Item

Consider where you fall on the idealism~pragmatism continuum. Advocate the opposite end of the spectrum with yourself in a mental debate; do you have anything to learn from those who position themselves differently?

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 →