The Old Man Story: How Extrinsic Rewards Kill Internal Motivation

I heard this amazing story recently and i will like to share it with you.

There was an old man that lives on a street corner where a bus picks the neighborhood children.

One day before schooolb bus came, the children saw the old man and started yelling insults at him.

“hey, old man, did you get yearly prostate exam yet”, “hey, old man, grim reaper is coming to get you”, “i heard you have a year book where you circle everyone who has died and you are trying to outlive all of classmates”

Eventually, one morning they went so far as to literally peeing in his yard. The old starting was infuriated. He decided he must do something about this abuse.

He thought to himself, “the children gets an intrinsic reward for insulting him and they enjoy doing it even if they didn’t get paid”.

One day the old man called the kids over before the school bus arrives and told them that if they came back tomorrow and yell some clever insult at him. He will pay them each one euro.

The children were thrilled. They ask within themselves, “how stupid could this old man be?”. The next morning , they came back ten minutes early just to yell insult at this old man. He paid them each, 1 euro each. And he told them, if they came back the next day, he will pay them 50 cents each.
And so they went to school with their money.

The third morning, they came back and he paid them 50 cents each. He told the children the same thing as last time except only 20 cents.
He did the same thing again with 10 cents and finally on the fifth day, on friday, he said he will pay them 5 cent each.

They struggle to come up with clever insults and told the old man, it’s not just worth it.
So they never insulted the old man again.

This is a perfect example of extrinsic reward killing the motivation for intrinsic reward. The children started yelling insults for free because it was fun. But by the time their payment has gone down twenty-fold. They found it wasn’t worth it.

They found that doing something they love in the beginning was not worth it after being paid.
And this happens in the real world. Painters, Artists or anyone who loves creating something, have been known to dislike the art after a couple of months of being paid.
It’s blast for a couple of months after getting paid for what you love but if the payment is not dependent on what you value of your work quality, your motivation level in your brain can go crazy.
It’s actually a fact of psychology.

Advertisements

Software Development: The importance of saying “no”.

Today I’d like to tell you about the importance of saying “no.”

For a year or two I worked as a consultant together with a friend, doing software development for a variety of customers. One of those customers was a research lab with a very small budget.

My friend had built a first pass, but when he moved on from consulting the rest of the project was left to me. Our customer only wanted a proof-of-concept, but even that was difficult to do with their budget.

In particular, they wanted us to build a video communication system: it needed to turn on automatically when a camera was plugged in, turn off when the camera was unplugged, and run over a network. And it needed to run on Windows.

This was a little tricky:

The initial prototype had been built with GStreamer, which was a reasonable technology to use, but I wasn’t familiar with it (or any of the alternative technologies, really.)
GStreamer had gone through an incompatible API change and it was difficult to get pre-compiled versions of the right kind for Windows.
Compiling it was possible… but I didn’t know much about Windows programming. Even just setting up a compilation tool chain would have eaten through a large part of their very small budget.
I managed to cobble something together, barely, within the budget they had set. It worked most of the time: you’d plug in a camera and suddenly you could do a video chat with someone on another computer. When it worked it was pretty cool.

However, sometimes you’d plug in the USB camera and nothing would happen. That was less cool. I probably could have debugged that given enough time, but they really couldn’t afford to pay for me to make it robust.

In any case, at this point I was about to move on to a regular job, so I handed over what I’d built and explained the caveats. Caveats or not, around this time they were supposed to have a major demo of the proof-of-concept I built. I never heard how the demo went; it may have succeeded, but there’s a decent chance it failed given how flaky the software was.

I never felt I did a good job for this particular client. Even as a proof-of-concept the software I delivered wasn’t very good. What should I have done differently?

In retrospect I should have said just said “no” to the customer: “No, I can’t do that with this budget. I don’t know enough to do it reasonably.”

Perhaps they would have found the extra budget, and so I would have had the time to do the work the right way, and fix any problems that came up. Or they would have realized what they were asking for was unrealistic. Perhaps they could have found someone cheaper to do the work.

Regardless of what they chose, they would have had a better outcome than what I provided by agreeing to the job.

Don’t make my mistake: don’t say “yes” to impossible tasks. By agreeing to do them you’re agreeing to solve the impossible, and that rarely turns out well.

Demonstrating open/closed principle

Recently i went for an interview, one of the best actually, one of the practical questions they asked was around Open/Closed Principle of SOLID.
The SOLID principles is one of the most asked questions in an interview for a O-O software developer. Most companies ask you to define or explain them and few ask to demonstrate them.

In this interview, i was asked to first explain what the “O” in SOLID stand for.

software entities(classes,modules, functions etc) should be open for extension and closed for modification.

Then apply it to this problem domain

Given we have a logger, with the following code, that writes to the File System, Expand its functionality to allow us to send email when we do logging.


public interface ILogger
{
public void log(string $message);
}


public class FileSystemLogger : ILogger
{
private readonly string filePath;

public FileSystemLogger(string filePath)
{
this.filePath = filePath;
}

public void LogMessage(string message)
{
using (var streamWriter = new StreamWriter(filePath))
{
streamWriter.WriteLine(message);
}
}
}

With solid principles in the back of my mind, i know the code for FileSystemLogger can not be changed. But can it be extended?


public class EmailAndFilesystemLogger : FileSystemLogger
{
public EmailAndFilesystemLogger(string filePath) : base(filePath)
{
}

public void log(string message)
{
base.LogMessage(message);
//...send email with message
}
}

The approach is nice and simple but it has some major drawbacks. First, it violates the single responsibility principle. Second, following this pattern, any future requirement like “add database logging” would add another level of inheritance and coupling. Third, any change to the base class could break everything.
So inheritance doesn’t work nicely here.

What about its partner, composition,


public class EmailAndFilesystemLogger : ILogger
{
private readonly FileSystemLogger fileSystemLogger;
public EmailAndFilesystemLogger(FileSystemLogger fileSystemLogger)
{
this.fileSystemLogger = fileSystemLogger;
}

public void LogMessage(string message)
{
fileSystemLogger.LogMessage(message);

//...send email with message
}
}

This is a better approach. It solves the business requirement but there is no way to perform emailLogger on its own.
So let’s separate it out.

public class EmailLogger : ILogger
{
private readonly ISmtpClientWrapper client;

public EmailLogger(ISmtpClientWrapper client)
{
this.client = client;
}

public void LogMessage(string message)
{
var mailMessage = new MailMessage {Body = message};
client.Send(mailMessage);
}
}

This looks good. Easily testable. What about the business requirement? How do we log to a file and send email as well.
This sounds like a job for Aggregator. Aggregator combines and uses indepedent objects.
SO, an aggregator for our requirement will look like this.

public class AggregatorLogger : ILogger
{
public AggregatorLogger()
{
loggers = new List();
}

public IList loggers { get; }

public void add(ILogger logger)
{
loggers.Add(logger);
}
public void LogMessage(string message)
{
foreach (var logger in loggers)
{
logger.LogMessage(message);
}
}
}

This code is easily testable, extendable and adhered all of the SOLID principles.
Full code and tests are on my github.

Thanks for reading.

Rotating developers within a company

I had a thought recently about rotating developers

I believe that there are a lot of good reasons to rotate the developers at your company onto other projects more frequently than you already are. What I mean by “rotate” is that a team member is effectively moved from one project to another. This is usually in the form of a trade. A developer from one project switches places with the developer of another project. They’re still around to help anyone working on the old project, but it is no longer their primary roll.

Just how frequently am I suggesting that developers should rotate onto new projects? In my opinion, a developer should be on a new project every 6 to 12 months. But this is something your company should experiment with to find an ideal length of time.

I don’t want to act like rotating developers is all advantages. But I shall discuss the disadvantages in a future article. Here’s why you should rotate your developers onto different projects:

Rotating developers helps them understand the big picture

Lets go extreme and imagine that one of your developers worked on every single project at your company. They would be intimately aware of how all the pieces fit together. They’d understand why a request to another team is reasonable or unreasonable given their constraints. They would have insight into the best place a feature to be implemented and be able to break down high level requirements into low level stories that are distributed to the rest of the teams. And, the chances that all the pieces would fit together in the end would be improved.

Consider that not all projects are user facing. Some projects are merely APIs for other projects. The people stuck on these API projects have a difficult time seeing how the features they are writing are providing value to the end users. Rotating these developers onto user facing projects will give them empathy for the customers and help them make decisions on their behalf. This decision making advantage will carry oven even if they are rotated back onto an API project. If a developer from a user facing project rotates onto an API project, they can bring a lot insight to the rest of the team for the same reason.

Rotating helps with a shared context

There’s a company maturity level required to even be able to rotate a developer from one project to another. Unless there’s a good support structure (documentation, onboarding, pair programming, etc.), a rotation will not go well. This support structure requires a way to share context. Without this – worst case scenario – it will be as if both developers quit. This would occur if you only had one person teams and after rotation, the two people never communicated with each other. Without being able to share context about where they left off, the ramp up time for being effective on their new projects will be astronomical.

The reality is that any developer is free to quit any time they want. So avoiding rotation does not avoid this concern, it just stops you from dealing with it until it’s too late. Better to deal with this risk head on today than at the worst possible moment tomorrow.

Rotating increases collaboration

With a large enough company it can become possible for projects to depend on each other with limited collaboration. This is a problem and here are a few symptoms of it:

  1. Work that is frequently blocked waiting for other teams
  2. Components that don’t fit together (e.g., an API nobody uses)
  3. Features that nobody uses

Frequent rotation will help alleviate these problems. It will also give developers direct contacts with people in other projects and that can pay off in unexpected ways.

Rotating empowers anyone to fix issues on any project

Once a developer has worked on a project, they will feel comfortable fixing issues on that project. When a company does not rotate developers this is not the case. When a project has production issues the developers of other projects wait for the developers of that project to fix it. This doesn’t have to be the case. With sufficient trust and collaboration, any developer could feel empowered to fix any production issue regardless of the project.

Rotating can reduce employee churn rate

A lot of developers start to look for a new job when they feel their current job has stagnated. It’s no fun to know everything you’re going to do day in and day out for years to come. Another reason developers quit is that they want to work with new people or learn a new technology. Rotating gives a developer all of those opportunities with very little downsides (relative to having an employee quit).

Some projects are less fun than others. If a developer is stuck on a bad project and it feels permanent, they’re likely to look for a new job. But if a new project is 6 months away, the bad project will be temporary and an employee is more likely to stick it out.

Rotating is an opportunity to learn

Having a developer stuck on a project for years is like having a developer live on a little knowledge island. They are learning things that would be valuable to share with others. Others are learning things that should be shared with them. When the organization structures these communication boundaries so developers can’t share experiences, everyone is left to their own devices to learn.

This is inefficient because some islands that others have already learned. Some islands may never learn a lesson that they should.

Rotating gives developers an opportunity to improve code quality

I’m working on a project right now that has had over 4 people rotate on. Each time a new person rolls on, they point out a low hanging fruit for improving the quality and stability of the code base in their first week. Why does this keep happening? Because a pair of fresh eyes can easily see the eyesores that the rest of the team has learned to adapt to over time.

When developers know they will be rotating onto new projects and responsible for sharing context before they leave, they’re going to be encouraged to write maintainable code. It’s far too common for a developer to silo knowledge so that nobody can understand it but them. Frequent rotation reduces this risk by addressing it earlier.

Rotating can reduce ego

Pride can be a good thing when it improves code quality. But ego can get in the way of code quality and cause developers to silo the knowledge of their project. Frequent rotation reduces this problem to a 6 month period because that’s the longest that an individual can “own” their code. I’ve discussed in other articles why code ownership is a bad thing.

I will say that there are more effective ways to deal with this issue (pair programming comes to mind).


Hopefully these advantages have convinced you that your company should be rotating developers onto new projects more frequently. Feel free to reach out to me if you have any questions or concerns.

Literary amble around Paris

They say you can never be lonely if you have a good book in your pocket. And if you are in Paris and the book, in question is “A moveable Feast” by Ernest Hemingway, this couldn’t be closer to the truth.

The first chapter is entitled “A good cafe on the Place St. – Michel”

Now here is a recommendation to top those of Lonely planet!. starting on Rue cardinal Lemoine, you can encounter a variety of literary ghosts, and literary haunts alike, if you know where to look.

If you’ve just arrived in Paris and dont know yet your way around, start the journet by taking the metro to Cardinal Lemoine, in the heart of the Latin Quarter.

From here, walk along Rue Cardinal Lemoine until you reach No.71: in one of the courtyard flats behind the gates, James Joyce finished editing “Ulysses” in 1921. If you are lucky, some unsuspecting frenchman has left the gates open. Then you might be able to walk into the courtyard and look for the original flat marked, “E”. Further long the rue, at No.74, is the apartment where Hemingway lived with his wife Hadley from 1922 to 1923. It’s worth taking a moment to imagine the Paris of twenties, with all the glitz and the glamour, when arties and social butterflies fluttered from one party to the next, dangling pearls bouncing gaily on their bosoms. It was on one such occasion that Jake met Bret in Hemingway’s “The sun also Rises”, Take short detour to no.39, Rue Descartes, nearby, which has a double claim to fame: the poet Paul Verlaine died in this hotel and, moreover, Hemingway used to write in an upstairs garret. From here, walk to Place Cpntrescarpe, wehere you can admire its windswept trees so eloquently described in “A moveabe feast”. Open said book on page 1: the establishment at no. 2- 4 once called Cafe de Amateurs, but now renamed Ccafe Delmas, is described as “the cesspool of the Rue Mouffetard”!. This rather ungenerous description, thather than deterring today’s cleintiele, probably draws literary connoisseurs into the , no doubt ver respectable, Cafe Delmas.

From here, it is possible to follow Hemingway’s own direction towards Place St. – Michel. On the way, ame a stop at No.6 Rue du pot de Fer, which was George Orwell’s boarding house, where he stayed while working as a plongeur, a dishwasher. His experiences of poverty and abandonment are vividly described in “Down and out in Paris and London” (1933). In this insightful book, Rue de Pot de Fer is called ” Rue du Coq D’Oe” and it is filled with eccentic characters and voices of misery. As you make your way past Place du Pantheon, “A moveabe fast” at hand, the anticipation of a good cafe au lait is likely yo be uppermost in you mind. It is worth wating just a little longer. stroll down Boulevard St-Mcihel, past the used-book shops and the gated greenery of the Jardin du Luxembourg (well worth a visit, by the way), until you finally reach Place St-Michel. Here, an absolute must see is “Shakespeare and Company”, a charming little bookshop where you can indulge in English language titles. It isn’t original homonymous shop owned  by Slvia Beach, who publised “Ulysees”, but what a magical place it is all the same. Here, aspiring writers sleep on the rugged old couches on the first floor, in exchange for working in the bookshop. Qui, c’est magnifique ca!.

A nice hot drink is probably a necessity at this point, reminding you that one cant live on Litereature alone!.

Unfortunately Hemingway does not give the name of the “good cafe” that he describes , but the famous “Les Deux magots” is not too far, on boulevard St-Germain. This elegant cafe used to be frequented by the likes of Sartre, Hemingway and Andre Breton and the hot chocolate is well worth the trek.

It is true: literary paris is guarenteed to entertain and fascinate any tourist who has time to dig a little deeper intto this city’s marvelous history.

If you have time, there is another obligatory destination: the Pere Lachaise cemetrey, where grears as Oscar Wilder, Gertrude stein and Honore de Balzac are buried. you may get lost among the graveyard labyrinth, so dont forget to bring a map at the entrance. you might also opt to take a flower with you, as amny so to posr on the final rewsting place of Oscal wide.

So can any city rival Paris on its literary richness.Dublin could certainly put up a fair battle, as could London. I’m off to London, next month, i hope to report on my adventure