Tuesday, February 28, 2012

Product Religion

Evangelists
Fanboys.   Zealots.  Fanatics.   These are words that have been used to describe groups of people who have a fervent belief or faith not in their God or moral belief system (well, ok, maybe sometimes) but rather in a particular technology or product.   Guy Kawasaki even brought it to a full-on professional title when he was "Chief Evangelist" at Apple - a title with all kinds of mixed marketing, emotional, and religious connotations.

Confession Time
Here is the point in the post where I make my confession:  I was a fanboy at one time.   Back in the early/mid '90s, IBM had an awesome piece of software called simply OS/2.   At the time, it was significantly more advanced than Windows and had the backing of the largest computer corporation in the world.   It seemed destined for legendary status and had allowed desktop PCs to do things that were previously either not possible or terribly expensive.   I even built a business on it with a friend and did some evangelism myself as part of a group known as "Team OS/2".    In the end, IBM changed directions OS/2 - and everyone who had depended on it - were left high and dry.    Although it was a great time in my life, I've wondered several times if I made the decisions within the right frame of mind.   If I had it to do all over again, would I make the same choices?    Maybe, maybe not.   I would, however, look at things from a slightly different perspective.

It's Not a Two Way Street
The problem with product religion is that the organization producing the product/technology/etc. is far less loyal to you than you are to it.     They may change their plans in a such a way as to negatively impact their loyal followers without any concern or regard for doing so.    It's been done many times over the years - TV producers abandoning shows such as Firefly, Jericho, and others with a small but vocal following,  the Houston Oilers abandoning Texas for Tennessee, and so on.

There is nothing wrong with being excited about a particular sports team, technology, or product.    The danger comes from making important decisions based on emotional rather than intellectual or logical reasons.   Although decisions can and perhaps should have an element of intuition or "gut feel", they must be backed by data and sound reasoning.

What product/technology/sports team are you fanatical about?   Why?  What would you do if the product was discontinued, the technology obsoleted, or the sports team was relocated tomorrow?



Friday, February 24, 2012

Time to Step Off the Trane

Moving On
All voyages have a beginning and an end, and for me today was the end of one such journey.    I first started with Trane in August of 2000.   Since then, I've been involved with a number of product development efforts  and eventually designed the basic software architecture used in most of the Tracer Evo embedded controls in addition to doing some R&D work on upcoming products and applied technologies.    Today, however, I bid farewell to my mentor/manager and coworkers as I prepare to move  on to a new and exciting opportunity at a startup in Edina called Jingit.

Why?
The obvious question is, "Why did you choose to leave?"   Part of the motivation for moving on was stagnation - there is only so much software technology involved with running a commercial building's HVAC system (but a lot more than you might expect).    When the opportunity came to move into a position at a much smaller, but more agile organization that is making use of mobile, social media, and other current technology trends, I decided that this would be a good move.      


While I took a fairly significant "haircut" in salary, I'm ok with that.    For me, happiness doesn't come from the amount on the paycheck.   Sure, it matters to a certain point, but day-in and day-out I am more engaged and motivated by challenges and the opportunity to help "put a dent in the universe".     And while some folks point out that a startup is less stable than a large company, I can't say a large company doesn't have it's share of layoffs, outsourcing, facility closings, and so on.   In the end, it was Jingit's value statement and leadership, in addition to the concept, that I found particularly engaging.  The basic idea is that a team of highly capable people combined with a fairly small set of rules and processes can produce excellent work at a lower cost more quickly than is typically done at a larger organization.    This will be an exciting change and a challenge at the same time.    It's exciting because given the team of people I'll be working with, I firmly believe that what took months to accomplish previously can be accomplished in weeks.   It's a challenge because what would have taken months previously must be done in a much shorter time.   That's the excitement and challenge of working at a startup.   I think Jingit has some excellent folks and a great vision accompanied by a realistic plan to get there, and I don't think I've been this excited about starting a new position since ... well ... ever.    Check it out at www.jingit.com.  

Looking Back
There's a certain amount of melancholy that goes along with this move - some of the brightest people I've had the opportunity to work with along with the best manager I have ever had have been at Trane.    I really value the time I spent at Trane and am grateful for the things they taught / re-taught me:
  • Leaders innovate change.   Managers copy success.    The roles are not interchangeable, and finding the right mix is key.
  • Sometimes, it's more valuable to help a team fail faster than to try and convince them about how to do something differently.  This allows everyone involved to internalize "the wrong way" of doing things and therefore builds the notion of "we won't make that mistake again" in the group's collective knowledge base.
  • Working on "the project from hell" and succeeding really polishes a development team - it's the whole "shared adversity" thing.   I know of no team-building substitute which is as effective. 
  • You can't be a prophet in your own village.     Know when to seek others' help on getting a particular message across.
  • Avoid those who believe process solves all problems.    As Phillip Su wrote, "Don't fear process.  Fear bad people dictating process.  Fear process trying to make up for bad people". 
  • "Visibility" is often identified as the thing needed for advancement.    I don't agree - I think visibility is a byproduct of innovative and excellent work.    If you produce innovative and excellent work, you will naturally advance within an organization.
  • Forced collaboration is a harbinger of doom, but organic collaboration is simply delightful.   The capabilities of a team whose members collaborate organically aren't added together, they are multiplied.
  • Analysis paralysis is death - bias must be towards action.   At the end of the day, the team must ship a product.
  • Don't sweat the mistakes, learn from them.   If you aren't making mistakes, you probably aren't making anything.
  • A company can espouse ethics, integrity, quality, etc. all they want, but who is placed into leadership positions and how projects are run will reflect the actual value system of an organization.
  • Nobody is good at everything, but everyone is good at something.    Matching someone's capability to a need is a win for everyone and brings great satisfaction to all involved.
  • The best technical ideas often come not from a leadership-directed investigation, but from someone who is engaged and asks, "What if...".    The best managers are those who allow you ask the "What if..." questions and then constructively challenge you on your answers.
I'm really excited about what the next page of my career might bring and the things I will learn from my new coworkers!    What have you learned from your coworkers recently?


Tuesday, February 21, 2012

The Curse of Knowledge

Try This
Try this with a friend - using only your fingers, tap out the rhythm to five or six well known tunes - The Star Spangled Banner, Mary Had a Little Lamb, Jingle Bells, etc.     Have your friend write down the names of the tunes without giving them any hints or suggestions.    Once they have done that, write down your estimate of how many of the songs they got correct.   Compare notes.

The Problem
I recently finished reading "Made to Stick", an excellent book by Chip and Dan Heath on why some ideas seem to find traction while other ideas disappear.   The book references a Stanford study performed by Elizabeth Newton in 1990 which used a similar scenario and found a significant difference between the number of times the "tapper" thought the audience identified the song and the number of times the song actually was identified correctly.   Chip Heath refers to this as "The Curse of Knowledge".   Essentially, the more you know about a topic, the more difficult it is to communicate meaningfully about that topic to those less informed.    The knowledge you have seems so obvious that the audience is assumed to have it as well.     The audience, for their part, doesn't want to seem ignorant or naive and so rarely ask clarifying questions.

The Curse in Action
I have observed this phenomena a number of times in different situations: discussions at work between software developers and non-technical staff, car buffs describing their hot rod, and even Sunday morning sermons.   I've seen others do it, and I've participated myself in both presenter and audience roles.   In each case, the expert (the one talking) referenced concepts or things not familiar to the audience and thus presented an obstacle to knowledge transfer.    If I were to tell you that I had been studying the Gospels, you might not know what I was referencing if you were not brought up in a Christian home or had that faith as a component of your life.    To someone who had that life experience, however, they would immediately know that I had been studying the books of Matthew, Mark, Luke, and John.   In this example, "the Gospels" can be considered to be technical jargon - something that is already known to someone who possesses a level of knowledge about the topic but unfamiliar to those who do not.

The Solution
Like most problems, this is easily dealt with once identified and understood.   My approach to solving this problem is to avoid using technical terms, and using analogies  to relate the topic or idea to something else in the listener's realm of knowledge.    I find that although it takes slightly more time to explain something using this approach, the other person is able to understand the idea more readily.

Some would argue that I have thus not been contaminated with knowledge.   How do you share knowledge with others?

Tuesday, February 14, 2012

Curiosity

Curious...
A couple of years ago, during my annual performance review with my manager, we were discussing some of the different things I liked and disliked about the working environment. One of things I noted was that I was perplexed as to why a segment of the engineering staff always wanted to be sent to training to learn new technologies while the other staff did NOT want to be sent to training. Both groups wanted to learn the technology in question (Javascript) but some felt that it was better to go to a formal class while others wanted to learn on their own.


Wash, Rinse, Repeat
The thing that stuck out in my mind was not the differences in learning styles (both are valid) but rather that the majority of folks who wanted to be sent to the class seemed to be missing a natural curiosity about the topic. Curiosity is something that I value highly in others around me; it is what drives them to ask questions and thus drives me to ask other questions. The answers often raise other questions, which leads into a neat cycle of learning. Curiosity leads to questions, questions lead to answers, answers lead to knowledge, and knowledge leads to curiosity.

An Example
Last year, my curiosity led me to an interesting place. Normally content in the technology / software / hardware areas, I stumbled across a reference to an article in the Harvard Business Review. As I read the article (it happened to be about a specific approach to innovation), I became interested in learning more about related topics such as R&D strategies, budgeting and scheduling when the task is not clearly defined, and more. The cycle of curiosity had taken me in an entirely new direction, and I have benefited from the knowledge gained in both my personal and professional lives.

Nurture It
Although I think I was a naturally curious person previously, that experience demonstrated to me the importance of curiosity. I think it is important to find the answer to some question each day. Many people make a point of walking or running on a regular basis to keep their body in shape. Learning is exercise for the mind, and as such I don't think it is important if the knowledge gained from the answer is immediately useful or not - the benefit is the mental exercise. It's almost a bonus that in doing this, you know more than you did previously. Even better, there is virtually no downside - no one ever threw their back out by reading a book (except my friend Bill, but I digress...).

So what have you learned recently?

Monday, February 6, 2012

Trigonometry for Web Developers, Part Three

Recap of Part Two
In part two of this series, we learned about the use of the sine and cosine functions and how they can be used to transform a set of polar coordinates (angle and distance) into cartesian (x,y) coordinates.   We  then used them along with an HTML canvas object and the associated translate() and rotate() methods to draw tick marks and labels on our canvas object.    In this final installment, we'll add a needle to our meter and learn a bit about how to efficiently animate it to display rapidly changing values.

Drawing the Needle
Our analog meter example wouldn't be complete without a needle to indicate the current value.    Just like on a real meter, the needle on our example pivots on one end around a point centered along the lower edge of the canvas while the other end points at the value to be displayed.    Conceptually, this is just like drawing another tick line as we did in the previous example: we will compute the angle and then use it, along with a predetermined length, to find the polar coordinates for one end of the line.   We will then draw the line using those coordinates along with the center bottom of the canvas.

The Javascript code required to draw the needle is straightforward.
// Determine the angle of the needle
needleAngle = startAngle + a_value * ((endAngle - startAngle) / 10.0);

// Draw the needle
ctx.clearRect(0, 0, cvs.width, cvs.height);
ctx.beginPath();
ctx.moveTo( centerX, bottomY );
ctx.lineTo( centerX + Math.cos(needleAngle) * (radius * 0.80), 
            bottomY + Math.sin(needleAngle) * (radius * 0.80));
ctx.stroke();
The angle of the needle is first determined by finding the polar distance between the starting and ending angles.   That distance is then divided by ten (the range of our scale), then multiplied by the value.    This result would be all that was needed if the zero value of the needle was aligned with 0 degrees on the graphics context, but in order to match it to the meter's face, the starting angle must be added.
Similar to drawing the tick marks, the drawing cursor is moved to one end of the needle's position and line is then drawn from there to a coordinate determined through the use of sine and cosine functions.

Adding a Layer
While it is certainly possible to draw the needle on the same HTML canvas as the tick marks, labels, etc. it is not very efficient to do so.   Consider that the needle may need to move frequently, thus needing to be redrawn, but the face of the meter is constant.   It would be very inefficient to re-draw the entire meter every time the value to be displayed changes, so we'll use two canvas objects: one for the labels and other items which do not change, and another for the needle.   We will then place them "on top" of each other, with the canvas for the needle in front.   This allows the animation to be much more efficient:  we can draw the face of the meter only once, and draw only the needle when the value is changed. 
<div style="width:500px; height:250px;">
  <canvas id="meter" width="500" height="250" 
          style="position:absolute; left:0; top:0; z-index:0"> 
  </canvas>
  <canvas id="needle" width="500" height="250" 
          style="position:absolute; left:0; top:0; z-index:1"> 
  </canvas>
</div>
The HTML required to set up the layering is shown above.     Notice that each canvas object is given an absolute position within it's containing DIV object.   This is what causes the canvases to appear to be "stacked".   Also, note the z-index value in the style attribute; this is what determines which canvas is "in front".    HTML objects with increasing z-order values will appear "closer" to the user than those with smaller values.  

The full HTML source which demonstrates drawing the needle into a separate canvas can be found here (FF, Chrome, and IE9).


Going Further
As you have seen, combining trigonometry, the HTML canvas object, and some Javascript can yield some neat results.   While it is beyond the scope of this series of articles, the HTML canvas object has some powerful drawing features.   Using the trigonometry concepts presented so far along with not-a-lot-more canvas object methods, you can produce impressive results with relatively little effort - click on the clock for the full-size, animated version (FF, Chrome, and IE9 only) :

This example uses the same techniques described previously, and adds some visual enhancements through the use of gradient fills, shadowing, and line style features of the HTML canvas object.    Like our sample meter, two separate layers are used: one for the clock face, numbers, etc. and a second canvas that only contains the clock hands.     No images were used for this example, so even without minification or other optimization techniques, the file size comes in at around 8KiB which provides for excellent performance even on slow links.

Wrapping It All Up
There is much more that could be done with this relatively simple example, but we have now covered the basics needed to handle angular data and use trigonometry to transform it to the x,y coordinate system used by the HTML canvas object.    If nothing else, remember this :
  • Math functions think in radians.   Convert degrees to radians by multiplying by π/180.0 and convert radians to degrees by dividing by π/180.0.   
  • cosine(angle) returns an X-coordinate, normalized to values between -1.0 and +1.0.   Multiply this value by the radius and add/subtract as needed to move the center of the circle away from X-coordinate 0.
  • sine(angle) returns the Y-coordinate, normalized to values between -1.0 and +1.0.   Multiply this value by the radius and add/subtract as needed to move the center of the circle away from Y-coordinate 0.
A little trigonometry added to an HTML canvas is an easy way to build an experience for your site that is fresh and different from the majority of rectangular, boxy sites which exist today.     What can you build with a little trig?