Skip to main content

A Tale of Tails

Every weekday morning, my family goes through the same routine:  I get up first and head downstairs for coffee; then our 4 year old wakes up and kicks my wife out of bed; at 8 am, I let the dog out back to relieve himself and get his morning meal ready while he is doing so; etc.

This morning, I observed something rather fascinating about our dog's behavior.  Due to the layout of our house and the orientation of the back deck, when I let him back in he takes off like a rocket.  Because we have hardwood floors, he can't turn at that speed and has to take a very circuitous route to get to the kitchen where his breakfast awaits.  I found this amusing because this is not an uncommon behavior in the professional world either.

Over the years, people often question what is more important:  design or execution.  I first encountered this seemingly philosophical (using that term very loosely) subject in college, where my professor in VLSI design stated unequivocally that a good design could be fatally hampered by poor execution.  My dog would seem to confirm this as well because even though his thought of going straight to the kitchen for breakfast is a good one, his inability to execute properly (i.e. slow down) forces him to take the most inefficient route to get to his food.

Balance is necessary
That's not to say that the act of focusing on goals should be relegated to the back burner completely.  Contrast the behavior of our canine pal with that of the Canadian rock band, Rush.  For over 30 years they have focused on one thing only:  making what they feel is the best music possible without regard to airtime on the radio or awards that they could possibly be given.  In spite of the fact that they have a rabid fan base, it is only now that they are finally nominated for induction into the Rock and Roll Hall of Fame.

Could they have arrived at this point sooner?  Yes, if they were willing to sacrifice the design of their band and focus instead on what the media expected (more radio friendly vocalist and songs to match).  But they didn't change their design even though it meant that they could possibly have never been nominated.

Careful planning to avoid unnecessary risk by developing contingency plans is a necessity to allow you to avoid making whimsical decisions on the fly that could eventually unravel your bigger plans.  But too much planning can yield an inability to execute due to a fear of never being ready.  The point here is that a healthy balance of design and execution is the ying and yang of business whether this applies to a product you are creating; your career; your ability to make a sale; etc.

Popular posts from this blog

"Ni jiang yi yang de hua ma?"

Last week, I wrote about the necessity of having a clear message . Because this topic is so important I decided to follow-up with another entry on this general subject. This week we will approach it from another angle. (For the curious, the title says " Do you speak the same language? " in pinyin, which is a transliterated Mandarin Chinese.) Recently, a good friend of mine (who is Chinese, ironically) and I were playing pool. He had to bank the 8-ball in the pocket to win the game, and since it was an informal game and bank shots are my area of expertise, he asked me for advice. I told him, "you just need to strike the cue ball with medium speed so that it hits the 8-ball right in the middle." He didn't believe me so we marked the positions of the balls, and then he took his shot only to watch the 8-ball sail past the pocket. "A-ha!" he exclaimed. "I told you it wasn't that easy." But when we reset the positions and I made an attemp

It's Easier to Fail at DevOps than it is to Succeed

Slippery when wet Since the term DevOps was coined in Belgium back in 2009, it is impossible to avoid the term whether in discussions with colleagues or in professional trade magazines.  And during the years while this movement has gained momentum, many things have been written to describe what elements of a DevOps strategy are required for it to be successful. Yet in spite of this, there is an interesting data point worth noting: not many organizations feel there is a need for DevOps.  In a Gartner report entitled DevOps Adoption Survey Results (published in September 2015),  40%  of respondents said they had no plans to implement DevOps and 31% of respondents said they hadn't implemented it but planned to start in the 12 months after the survey was conducted. That left only 29% who had implemented DevOps in a pilot project or in production systems, which isn't a lot. "Maybe it's because there truly isn't a need for DevOps," you say.  While that

Is No/Low-Code the Key to IT Nirvana?

 Unless you've had your head in the sand for the past year or so, you've seen the phrases low-code  and no-code  bandied about quite frequently everywhere you look.  You've probably wondered if this is something new that's here to stay or just a "flash in the pan."  Although the terms have been in the fore of the IT trade publications recently, Low Code Development Platforms (LCDP) (and the corresponding No Code Development Platforms) have been in existence since 2011.  Their roots can be traced to the 90's with 4th generation programming languages and GUI-assisted programming paradigms, e.g. IBM VisualAge for Basic, which was discontinued in 1998. For those of you who aren't familiar with either, the premise is that these platforms allow someone to quickly build applications using a WYSIWYG interface and a "click and configure" paradigm to Isn't this the source code to Roblox? rapidly build full applications with little or no coding requ