The Science of Motivation

January 29, 2010

As a manager, I’m interested in the subject of human motivation. There is a very interesting and entertaining video of Dan Pink – a writer and career analyst – giving a presentation at TED (Technology, Entertainment, and Design) on the Surprising Science of Human Motivation that I strongly encourage you to view.

Dan is very engaging as a speaker who believes that we are shifting to a corporate culture where creativity and big-picture design will dominate. In this talk, Dan discusses changes companies must make in how they manage creative people if they expect to survive. You’ll hear Dan make the following assertion sprinkled throughout the talk:

“There is a mismatch between what science knows and what business does.”

Quite simply, Dan points out that “extrinsic motivators are fine for many routine tasks where there is a simple set of rules to follow and a clear destination. Offering bonuses as incentives as part of a reward-punishment approach does not work for many 21st century tasks, where more difficult, cognitive skills are required.” Why?

Studies have shown that rewards have the effect of narrowing our focus and concentrating the mind, something that is highly desirable is there is a simple set of rules with a clear destination. But when creativity is involved, you don’t want to restrict thinking. In fact, you want just the opposite.

Creative, conceptual activities geared towards driving innovation do not have clear rules or a single solution! Dan points out that science has proven that if-then rewards can hurt productivity. He states:

“As long as tasks involve only mechanical skill, bonuses work as expected; the higher the pay, the better the performance. But once a task involves even rudimentary cognitive skill, a larger reward leads to poorer performance.”

How should 21st century workers be managed? Dan feels that intrinsic motivation is what matters; people desire to do things because they matter, because they enjoy it, because they are a part of something that is important. Have you heard this before?

Yes! Management has known about this for quite some time. Maslow's hierarchy of needs was published in 1943 and has been a part of management literature for decades. Management needs to catch up with the times and change its approach as the work forces moves higher up the pyramid and as innovation and creativity become increasingly important.

Dan points out that intrinsic motivation revolves around:

Autonomy: The urge to direct our own lives.

Mastery: The desire to get better at something that matters.

Purpose: The yearning to do something larger than ourselves.

His final thought: “Traditional management is about compliance. If you want engagement, self-direction works better.”

After viewing the talk, I found myself in complete agreement with Dan, but I had a few thoughts run through my head. I’m a Dilbert fan, and a couple of pointy-haired boss scenarios came to mind:
  1. An executive could get the message that they could “raise productivity” immediately by cancelling bonuses for all employees – yet they would somehow retain them at the executive level and even reward themselves with a larger bonus because they “significantly boosted productivity this year.”
  2. Managers would jump on the bandwagon with a poor implementation of Dan’s principles. It would look something like this:
  • Granting autonomy and completely backing away without effective coaching and guidance, assuming immediate mastery and ability to perform the work, even though culturally an organization may not have expected this in the past.
  • Being vague about the purpose and direction.
  • And finally, punishing people for failing to successfully reach vague goals, with assumed skills, and no guidance and participation from management.
I had another thought, and that is related to another dynamic that is in play. This is the desire to commoditize white-collar work to increase productivity. What Dan is talking about may end up being the norm for those fortunate enough to be at the top of the organizational pyramid, but for others the story might be very different. I explored this issue in a couple of posts in 2009:

Is Commoditized White-Collar Work on the Horizon?

How Commoditized White-Collar Work Will Change the Work Dynamic

What are your thoughts?

Book Review: Collaboration - How Leaders Avoid the Traps, Create Unity, and Reap Big Results

January 22, 2010

As our organization has migrated to Agile/Scrum development, the subject of collaboration has become more important for us to understand. Equally important, we are part of a larger, geographically-dispersed organization that is taking more aggressive action at operating as a single unit versus each business unit operating as a separate, independent entity.

The challenge is to realize gains in productivity and efficiencies while avoiding negative impacts. I happened upon the book Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results by Morten T. Hansen (© 2009 by Morten T. Hansen), and naturally enough I was intrigued enough by the topic to purchase the book.

The book really focused on enterprise-level collaboration, with little to offer at the team level. I did find the points about enterprise-level collaboration as important, since this is an area where significant costs can be incurred, with little to no gain if done poorly.

Collaborate with Purpose
Understanding when it is appropriate and useful to collaborate is vital, and Hansen points out three opportunities that you should be targeting to improve through effective collaboration:

Better Innovation. This is achieved when people from different areas come together to create new ideas through their interactions.

Better Sales. Increased sales can be achieved by implementing cross-selling as a collaborative exercise where different organizational units cross so that one unit can sell its products to another unit’s customers.

Better Operations. Various options exist to improve operations, such as centralizing certain functions, passing along advice (best practices), or re-using existing resources.

Hansen also warns about the danger of over-collaborating, where the act of sharing information and ideas can lead to more time spent travelling and less time getting work done. In day-to-day practice there will be a question facing people: To collaborate or not to collaborate? The issue confronting them will be to do their own work and not collaborate, or to take time to help others and not get their work done.

The obvious answer here is to make sure that the priorities are known, that way those who are faced with this decision will understand the trade-off that they are making, and ideally they will be aligning their decision with the priorities of your organization.

Being Productive in a Collaborative Environment
The above relates to another important point that Hansen makes, and that is in order to achieve a highly productive environment, you need the ability to focus your attention on getting work done while leveraging the collective skills of the organization through effective collaboration. This requires that people be able to work in two dimensions. The problem is that people may not be able to, or will need coaching in order to reach this level. Hansen categorized people as Butterflies and Lone Stars.

Buttterflies are those who work well across the company, but fail to do well in their own jobs.

Lone Stars are those who deliver on their own jobs, maximizing their individual performance, but running counter to collaborative, teamwork behaviors.

Being productive isn’t automatically achieved simply by putting people together, ether. If you want to be a collaborative leader, do not make the mistake of measuring only team output – individual accountability remains a vital component! I wrote about this in my post Accountability and Teamwork: Is Everyone Pulling Their Weight?

Create a Unifying Goal
While the concept of unifying people is achieved through the establishment of a common, motivating goal is common, I really liked the example that Hansen used to drive the point home. I wrote about this in my post One Key to Successful Collaboration: A Unifying Goal.

If you want to gain more insight into the art of collaboration, I highly recommend the book.

Eight Tips for Creating Self-Documenting, Maintainable Code

January 15, 2010

The cost of maintaining software is high. According to Robert Glass, maintenance is the dominant phase of the software life cycle, consuming 60% of the total software costs on average. Equally important, only 17% of maintenance is actually spent on fixing errors; a significant amount of time is spent enhancing the software. (Deciding if something is a defect or an enhancement isn’t always as straightforward as it should be, as I wrote about in my post Is it a Defect or an Enhancement?)

This makes it vitally important that the code is designed and written in such a way that it minimizes the effort to maintain it or enhance it. In my post What is Beautiful Code? I noted that “Beautiful code should be completely readable (by humans) to the extent that the code is literally self-documenting and something that can be easily maintained over time by others.”

What does completely readable, self-documenting, maintainable code look like? And does self-documenting code remove the need for any documentation?

Tip #1
A method or function should have a specific purpose and not try to do more than one job.

To improve readability and maintainability, move blocks of code to separate functions or methods:

CountLines(string startDirectory)
    totalLines = 0
    For each directory in startDirectory
        For each file in directory
            lineCount = 0
            Open file
            Close file
            totalLines += lineCount
    Return totalLines

This is a simplistic example, and the code snippet appears to be small enough to understand, but a simple modification to make the code readable and self-documenting would be:

CountTotalSourceLines(string startDirectory)
    totalLines = 0
    For each directory in startDirectory
            For each file in directory
            totalLines += CountSourceLines(file)
    Return totalLines

CountSourceLines(string fullPathAndFileName)
    lineCount = 0
    Open fullPathAndFileName
    Close fullPathAndFileName
    Return lineCount

There is now a specific method for opening a file and counting lines in the file, separate from method that drives the totaling, based on where it starts and what files it finds.

Tip #2
Don’t be ambiguous in your programming.

I’m as guilty of this as the next person, but developers constantly complain about vague, high-level requirements, yet many (not all) tolerate vagueness in their own code all too often.

Use clear, descriptive names for variables, constants, enums, and methods or functions. For example, in Tip #1, I have a method called CountSourceLines(), not something vague like Count(). I also made sure that the parameter for the CountSourceLines() method is descriptive; I expect a fully-qualified path and filename to be passed. If I had used a parameter called file, would the caller have known for sure what to pass? Not without looking at the code and possibly experimenting.

Method or function names should describe what the routine does, and the names should be precise and concise. Focus on the primary purpose; the objective is not to “self-document” everything into a name. A name like MethodToReadFilesAndCountSourceCodeLinesAndThrowExceptionOnError() is NOT good naming! If you feel like you are writing a sentence instead of a name, back up and start again.

The same applies to variables, constants, and enums. Name them descriptively and concisely, and by all means don't allow use of magic numbers and other discrete values!

If you have something that looks like this:

for i = 1 to 7

What is i, and what significance does the number 7 have? Sure, you could comment this, but why bother if you can write something like this instead:

for dayInWeek = 1 to NUM_DAYS_IN_WEEK

Tip #3
Declare variables as close as possible to where it is first used.

This works great IF your methods or functions aren’t so big that it is difficult to see the variable declarations. Some people prefer to declare all variables at the beginning of a method or function so that they are in one place, but I personally like to declare variables as close as possible to where I’m using them so that the reader understands why the variable is needed.

Tip #4
Write for clarity and maintainability first, optimize later.

Trying to write optimized code at the outset can create difficult to understand, difficult to maintain code. Write your code first and then profile it to find out where your bottlenecks are. You can determine what to change at that point. Remember the old adage: “An application spends 80% of its execution time in 20% of the code.”

And don’t get stupid! Follow sound design and development practices, learn about and make use of design patterns. Poor design will not only make maintenance difficult, it will also make optimization a challenge.

Here’s a link to a post about “optimizing later,” that is really poor database design, and something that never should have happened:

We'll Optimize Later.

If the reader needs a greater context to understand portions of your code, consider adding specificity and clarity in how the code is structured and written.

Tip #5
Comments should explain what you intended the code to do, and why.

If you’ve followed these tips, chances are that you can avoid spending time explaining what your code does. Self-documenting code with comments that explain why the code is doing what it does provides a fairly complete representation of the business and decisions that went into producing the behavior that exists.

Don’t comment the obvious, but if there is a difficult section of code, by all means, explain it! While you might believe that it is a great exercise to examine a piece of code to understand its “beauty” and function, if you are the person who is trying to fix it in a short time frame without creating any side-effects, an explanation goes a long way!

Tip #6
Follow your company’s style guidelines.

Yes, this might mean that you need to adapt and put the curly brace on a new line instead of at the end of the line, but consistency is one more step towards decreasing the time and effort required by your organization to enhance and adapt the software over time.

Tip #7
Good software documentation provides background information and descriptions of key decisions.

We’ve all seen the monolithic spec that is outdated before the first release, let alone what happens later. No one maintains the comprehensive documentation as much as they maintain the code. (How many of you are REALLY maintaining your documentation?) If there is a question about functionality, the definitive answer comes from someone referring to the code, not the documentation.

A major problem is that while a developer can tell you what the code does, many times he or she cannot tell you why it is doing what it does. If your code is self-documenting with comments that describe the intent of specific methods, functions, or sections of code, then all that is left is documentation that describes the business objectives and higher-level decisions, with no need for a monolithic spec.

Tip #8
Tools can be used to confirm that your code is maintainable.

There are tools available to facilitate code reviews along with checking for vulnerabilities or performing something like a cyclomatic code complexity check, and to provide measurements on things like cohesion and coupling.

What is Beautiful Code?

January 8, 2010

The book Beautiful Code has sparked a variety of opinions. A couple of critical observations about the book:

It has a variety of authors, and the book comes across as a collection of independent essays, with each chapter standing on its own.

More often than not, there is no real discussion from the authors about what beautiful code really means to them.

I thought about my own definition of beautiful code and decided to solicit the opinions of others on LinkedIn to see if they shared my opinion. I received some great responses, and let me once again thank everyone who did respond. The majority of the respondents felt (as I do) that beautiful code is something that can be easily maintained over time, and not something expressed in an "artful" way that requires study for a period of time to appreciate its beauty – and to understand its function. There is a definite difference between was is desired in the working world and what would be acceptable as “art” in other settings.

In particular, I’d like to expand upon (and slightly modify) one response from Bidyut Raj, who provided a truly great analogy.

Beautiful code is like a diamond.

The diamond metaphor defines beautiful code and explains why beautiful code is more valuable than ugly code. The analogy covers the 4 C’s of a diamond as well as the setting of the diamond. Consider the following in terms of both the definition and value of beautiful code.

Clarity describes the purity of a diamond, and is determined by the number, size, and location of imperfections. The fewer imperfections that a diamond contains, the more beautiful the diamond is.

Ergo, beautiful code should not contain imperfections, whether these imperfections are design flaws, bugs that lead to problems during execution, or even the use of confusing, inconsistent coding standards.

The best color for a diamond is no color at all. A totally colorless diamond allows light to pass through it easily.

The interfaces of beautiful code should be intuitive, simple, and easy to use, whether the interfaces are programming interfaces that another programmer invokes or the user interface that customers utilize to interact with the software. Beautiful code should be completely readable (by humans) to the extent that the code is literally self-documenting and something that can be easily maintained over time by others. The expression of logic should be precise and understandable, which means that the code should not contain arcane tricks that can take an extraordinary amount of time for someone else to decipher.

Cut refers to the proportions, finish, symmetry, and polish of the diamond, factors that determine the fire and brilliance of a diamond.

Beautiful code should have a design and implementation that meets the functional and non-functional requirements to such a degree that anyone looking at the code recognizes the brilliance in the craftsmanship of the code. Like diamonds, this is difficult to quantitatively judge, but a great “cutter” (programmer) can significantly influence the value of the code, and can even transform existing, ugly code into beautiful code.

The carat is the unit of weight for a diamond, with value increasing with carat size.

Beautiful code should “weigh” just enough to get the job done, and no more. The weight of software should be a function of the business value that it is providing, and there should be a need – and value – derived for each and every task that the software performs. If the code weighs more than the value being derived, it should be scrapped or re-cut. Conversely, some code returns a great deal of value in comparison to its weight (and other code), which translates into higher profit margins or savings in terms operational efficiencies in some way for the owner of the code.

Diamond settings are the platform in which the diamond sits.

The setting is the business context and need that the beautiful code fulfills, and what is beautiful in one setting may not be so beautiful in another. For example, a beautiful client/server, Windows®-based application may be elegant as an in-house, single-customer solution, but it will not shine in a Software-as-a-Service setting intended for a broad customer base.

Code Isn't Beautiful
Beautiful Code Diamond (gemstone)
The Four C's of diamonds

And many thanks to Bidyut Raj.