The essence of strategy is choosing what not to do.

- Michael E. Porter

It’s a good quote, but there’s a better one that cuts more to the heart of the matter:

No.

Attempting to say no and actually saying no are what many of us spend our lives doing.  When you often get in trouble, it’s because you said yes.

You said yes to a feature that turned out more complicated than you thought.  Now you’re working overtime to complete it.  What if you had said no?  How much would users care?

You said yes that you’d attend the meeting because someone asked you, but you learned nothing.  What work could you have done if you had said no?

The scenarios are endless.

No is the best response in many places, although sometimes the word no isn’t said at all.

I didn’t have time to write you a short letter, so I wrote you a long one instead.

- Attributed to Mark Twain, but there is debate about that.

What if you had said no to something else, so you had time to write that short letter?

Omit needless words.

- Strunk and White

Omit needless code.

- Kevlin Henney

Omit needless features

- Paraphrase of Steve Jobs.

The actually quote from Steve Jobs:

I know you have a thousand ideas for all the cool features iTunes could have.  So do we.  But we don’t want a thousand features. That would be ugly.  Innovation is not about saying yes to everything.  It’s about saying NO to all but the most crucial features.

- Steve Jobs

You hear this advice all the time.  If saying no is the way to go, then why  are we all so bad at it?

We’re like cats: the shiny new object always holds allure over the old and dull.  I can interest my cat with balls and bells, until the moment the laser pointer comes out.  The balls and bells are forgotten because the shiny non-catchable dot has appeared.

We’re all chasing laser pointers instead of balls and bells.  The ephemeral laser pointer promises a better future, whereas the balls and bells represent the solid here and now.

I recently tweeted this:

Let’s get something straight: no feature is ever “must have”.

Here are some of the replies:

Disagree.  Just need to understand context.

There are some features that are must-have, though not nearly as many as we think. I’m certainly guilty of this.

Both are a failure to say no.  We all fail to say no at times.  Think about this: what if we didn’t have that feature?  What’s the worst that happens?  Things stay as they are.  The world doesn’t end.

If you can’t say no, you end up thinking business software is messy and ugly.  Features accumulate and code spaghetties.  Technical debt piles on.  It’s a world of trouble, all of which results from not saying no.

Switching from business software to the personal, there’s a piece of advice oft repeated: follow your passion.

It’s clear by now where I’m going with this.  Follow your passion is another way of telling us to say no.  How do you follow your passion without saying no to everything else that might interfere?  If you don’t say no, you’ll find there’s little time left to say yes to what you want to do.

No is one of the simplest words in the English language.  It’s one of the first words that native English speakers learn to say.  Yet no is the hardest word in the English language to say to someone.

Knowing this, I challenge you: say no to someone and see what results.  Maybe saying no will become a habit for you.  As a result, the world will become a better place.

No

Book: Title

The title would be supplied by the user, but the product type would not be, it would simply be selected from a list.  This information would then be available to other users in various languages.  Since the title was user supplied, it was clear that nothing would be done to translate it.  Initially it was decided that the product type (book, in this case) would not be translated, but would be left in English.

At a low level this code interfaced with gettext.  There was some entanglement between the code that displayed the product type and gettext, which meant if a user where to view the page in a non-English language, then the product type would be translated.  But the decision had been to not translate it.

I was left with three options:

1. Do nothing – let the product type translate.
2. Copy the code to display the product type so that it wasn’t using gettext.
3. Rewrite how the application used gettext so that the product type code and the gettext code weren’t so wedded to other.

There were problems with each option:

1. This wasn’t the decision that was wanted.
2. This was easy, but now it meant the product type code existed in two places, and any updates would have to be applied in both places.  I could easily see it happening that an update made to one place wouldn’t be applied to the other.  This solution bothered me because it violated DRY.
3. This involved a massive rewrite that would solve the problem, but would take the most time and touch a lot of the application.

I went with option one:  do nothing – let the product type translate.  This meant I had to change no code, so it was the quickest and easiest to implement, while also not violating DRY.  This did go against the decision to not translate the product type, but after bringing up the issue with all concerned parties, it became clear that having the product type translate wasn’t a big issue.

The issue was resolved in the best possible way not because clever code was written, but because a non-technical solution was found.  Often, the first impulse for any developer (myself included) is to start typing and to stubbornly plough through any technological issues that arise.  However, sometimes the best way forward is to take the time to stop and ask people to consider their decision, because going a different direction might be easier and better for everyone.

The Best Solutions Are Non-technical

Teams with healthy idea life cycles are easy to spot: ideas flow between people easily and in large volumes.

Teams that innovate are great places for ideas to live – like happy pets, they’re treated well, get lots of attention, and are shared among people who care deeply about them.

The life of ideas is the responsibility of whoever is in charge.  He defines it by his responses and behavior, especially when he’s challenged by someone else’s ideas.

Teams with scorched deserts where creative jungles should be usually have the manager to blame.

– Selected quotes from pages 101-102, The Myths of Innovation: Chapter 7; Your boss knows more about innovation than you

Here’s another quote, that I’m sure you’ve heard: If you don’t have time to do it right, when will you have time to do it over?

Companies these days claim they want innovation.  IBM jumps to mind because of their commercials.  I’m reminded of the one of the guy in the super hero suit who runs around talking about ideation.  Unfortunately, this often doesn’t seem to be far from the truth.  Innovation is expected to happen at the snap of a finger, or during an hour long brainstorming meeting.

If innovation happens this way, how come our best ideas often come to us after we’ve slept on it or when we’re in the shower?

Companies don’t want to put in the time to do it right, so they’re often failing and hoping they have the time to do it over.

Innovation takes cultivation.  It doesn’t come overnight, it comes from a sustained culture that welcomes ideas.  It is that simple.  The more ideas, the more likely someone is going to find the magical combination that leads to the next great thing.

A corollary is that you can’t have innovation without experimentation.  I may offer you all the great ideas in the world, but if you never let me act on them, why am I going to keep offering up ideas?  You don’t have to indulge every idea I have.  I just need the occasional chance to explore further.  It doesn’t have to result in a final product or even a prototype.  It just needs to be enough exploration to see if the idea is viable.  That little show of confidence, that you have faith in me to let me pursue an idea for a bit, is enough to keep my intrinsic motivation charged, so I’ll keep suggesting ideas.

If you want innovation from me, treat me like a child. Let me play. It doesn’t have to be every day, or every week.  However, if you let me play, I’ll invent things you didn’t imagine, and we’ll be the richer for it.

For Innovation, Treat Me Like A Child

The dirty little secret – the fact often denied – is that unlike the mythical epiphany, real creation is sloppy.  Discovery is messy; exploration is dangerous.  No one knows what he’s going to get when he’s being creative.  Filmmakers, painters, inventors, and entrepreneurs describe their work as a search: they explore the unknown hoping to find new things worth bringing to the world.  And just like other kinds of explorers, the search for ideas demands risk: much of what’s found won’t be satisfactory.

- Scott Berkun, from The Myths of Innovation: Chapter 6; Good ideas are hard to find, p. 86

The quote above is why I advocate agile practices.  For me, it’s the number one reason to use agile: you can be messy.  You can explore and see what you discover, because you know that if it’s good, you’ll come back to it and refine it, and if it isn’t, you can throw it away with little time lost.

You can work with the knowledge that if you build up some technical debt, it’s okay; you’ll pay it off in the next iteration, before it becomes so large it bankrupts you.

Being agile enables risk, because the time blocks are small enough that there is time to recover.  And by extension, enabling risk helps to enable innovation.

Simply being agile isn’t going to cause you to suddenly be an innovation machine.  There’s a lot more to it than that, as Scott’s book points out, but being agile is a good start down the right path.

Iterating Innovation

What are the implications of a culture like this?  For one, it means everything has to be open.  All communication.  The fiefdoms that frequently come up in corporations couldn’t be allowed to exist, because as soon as they did, the culture would be destroyed.

More interesting though is that in such a culture everyone would have to be accountable.  No one could hide behind empty words or blame someone else.  Each person would be responsible for their failures as well as any team failures.  It brings to mind the motto of the Three Musketeers: “One for all, and all for one”.

Taken to it’s logical conclusion, what does accountability in a culture of trust mean?  It means that at any time if someone betrays the collective trust or avoids accountability they should be fired.

They should be fired.

Think about that.  I think everyone of us is used to feeling that we have job security.  Even if we slack off and perform poorly, it usually takes an act of God to get fired.  In a corporation that had a true culture of trust, this wouldn’t be the case.  There would be a revolving door as new people who failed to grasp the culture where let go.

However, those who embrace trust and accountability would have great job security.  They’re an asset to the corporation, so there’s no need to let them go.

Do any cultures like this exist today?  I suspect Google might be close, but I’m sure even they have their problems.  I agree with Scott Berkun that we suck at holding people accountable.  No one wants to be left as the person blamed for a failure.  In a culture of trust, having a failure on your resume wouldn’t be seen as an evil, so long as you accepted the failure and understood why it occurred.

Are we ready for this kind of culture?  Everyone’s knee jerk reaction is to say yes, but reconsider for a minute.  To be placed in such a culture would be stressful.  I’m not sure if people are ready to give up the stability of today’s general management structure for the more volatile one of a culture of trust.

A culture of trust would lead to more innovation and greater creativity; the rewards would be great.  It would rock if corporations made the switch.

Does any one know of a company that already has such a culture?  What other implications are there to a culture of trust?

A Culture of Trust

Service Oriented Architecture is only achievable through message passing.

It’s a simple concept that makes sense when it is articulated, but unless you consciously think about it is easy to miss.

Often, when different services are built for an application, they end up sharing the same database.  While this might seem like a good initial idea, ultimately it becomes a single point of failure as well as a bottle neck for the entire system.  The only way to avoid this is to split the application into two entire different systems that communicate through message passing, not through the database layer.

There are other benefits to this approach.  When each service is entirely separate from any other, then no service is bound by the technological decisions made for the others.  The development team is free to explore different technologies and options for each service.  The only requirement is that each service be able to talk to the the others, and protocols like HTTP make this easy, if not entirely trivial.

There is also the benefit that by decoupling services to the point that all that is needed is message passing, more creative ways to leverage the entire system might be found.  Each time a new service is incorporated, the only technical hurdle preventing it from talking to any other service is enabling it to pass the right messages.  This makes for a modular and reusable design at the service level, a further abstraction up from the code and library levels.

The proof that message passing works can been seen in languages such as Erlang.  Erlang nodes only communicate through message passing, not through shared memory, enabling Erlang’s exceptional concurrency handling.  Message passing at the service layer also provides the same benefits that Erlang enjoys at the language layer; redundancy, concurrency, and stability are all made easier by message passing.

The end lesson is this: Service Oriented Architecture is Message Oriented Architecture.

Message Oriented Architecture

I’ve also been following the various discussions and arguments on REST that seem to frequently flair up, although I’m lurking more for knowledge than contributing anything to what is being said.

It seems to me, based on my limited knowledge of REST, that Tim Bray describes a perfectly RESTful Interface when he talks about how he envisions a search API being designed, although he never mentions REST.

Very worth the read, as it provides a concrete example of what a RESTful interface can look like, which I find helpful so that I don’t drown in abstract details and descriptions.

A RESTful Interface

Jay’s point is that it isn’t enough to go through the motions of being a developer. Part of being a developer is understanding the point of the motions you’re going through.  If you don’t understand why, you can’t understand the good or the harm you’re causing.

Recently on a project, I checked in some Python code that used several try except finally blocks, looking similar to this stub code:

try:
    session.open()
    do stuff
except:
     handleException()
finally:
    session.close()

The code acquired a database connection and I used the finally block to ensure the connection was closed, preventing any leaks.

When working on the code I had inserted some tabs instead of spaces. When another developer opened the same code in his editor, it complained about the tabs vs. spaces, but didn’t offer an explanation for the error it was reporting, only reporting an error. The developer failed to ask why the error was being reported and also failed to ask why I had written the code as I had.

The result was that the code was rewritten as this:

try:
    session.open()
    do stuff
    session.close()
except:
    session.close()
    handleException()

There is now duplicate code in the form of the session.close() call and the finally block has been removed. The code is less explicit and more repetitive (although it happens to end up being the same number of lines).

Muddling of code and an unneeded rewrite occurred all because of a failure to ask why. Listen to Jay. Ask yourself why before you code and before you start changing code others have written. It will lead to better code.

Understanding Why

Yesterday, while performing the activity of brushing my teeth, I started thinking about some Erlang code I was writing in my spare time.  Also, previously at work, some of my coworkers had been looking at Fitnesse, which is contributed to by Bob Martin, and commented on how short the methods were.

With both of these thoughts fresh in mind, it hit me:

Small methods are the object oriented equivalent of side effect free programming in functional programming.

A small method is in effect an immutable variable that gets passed around.  At the very least, it minimizes and isolates side effects, while enabling easy refactoring and testing.  It’s the closest to side effect free programming you can get in OO.

OO Side Effect Free Programming

Tesler’s Law is this:

The Law of Conservation of Complexity: Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it.

In the interview Bill de hOra links to, Tesler further enumerates on his law:

If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalizing the user to make the engineer’s job easier.

Whose time is more important to the success of your business? For mass market software, unless you have a sustainable monopoly position, the customer’s time has to be more important to you than your own.

I agree. I think if we look at some of the most successful applications in history, we’ll find Tesler’s law at work behind their success.

Tesler’s Law