Category Archives: books

Book Review: Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman


Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover & Adewale Oshineye

There are some books that I wish were available 4 years ago when I first started working in the software development world, maybe even before I went to college. This book is definitely one of them. It’s not an easy task to concretely outline the practices that are helpful towards improving one’s skill as a software developer but this book does it well as Dave and Ade speak about their experiences as apprentices and how they grew to be journeymen.

I will point out the patterns that resonate the most with me and my quest to be a better developer.

1. Expose Your Ignorance
Context of the problem: Your team/clients/managers are expecting you to know what you’re doing and deliver value to the team but you’re unfamiliar with some of the required technologies or the domain of the project.

This situation happens to me on quite a regular basis every time I switch to a new project. It’s one thing to not know the domain of the application, it’s another to not be comfortable or familiar with the language or tools that are used on the project. When I started my first project at ThoughtWorks, I remember taking about 3-4 months to get up to speed and learn all the right questions to ask when working on a story. I have reduced that learning curve period since then, but it has always been a challenge to have to deliver on my first day on a new project.

Suggestions from the book:

  • Show your team and managers that the learning process is part of delivering software.
  • Get used to learning. Craftsmen will have to work with different technologies and domains over the course of their career. Those who stick to just one domain/technology are called experts. Expertise is not the goal of the apprentice.
  • The most important trait of a craftsman is the ability to learn, identify an area of ignorance and working to reduce it.

2. Confront Your Ignorance
Exposing your ignorance will be of no value if you don’t do anything about it. There will always be tools and techniques that you need to learn and master and you have to start somewhere.

I usually do the following:
- read documentation, APIs and FAQs
- if it’s open source, attach the code so it’s easier to look at what’s going on

Things I should really do more of:
- write a scratch application to use the new tool/library
- actually dive in to the code, if there is any

Things I am currently trying to do:
- start from scratch and learn about a language from the ground up. I recently picked up the book C# In Depth by Jon Skeet to learn about the innards of C# starting with C#1 onwards to C#3. I also was reading Programming Clojure by Stuart Halloway (but sadly that has been pushed to the wayside).

3. Be The Worst
Some people find it discouraging when they realize that they are the least experienced person on their team. I, however, find that exhilarating because I know the opportunities for me to learn will be endless. Being the worst on your team shouldn’t disheartened you, but it should push you to work harder than anyone else because the goal is not to stay the weakest, it is to work your way up.

Enthusiasm and passion can be contagious and I have my coworkers at ThoughtWorks to thank for always pushing me to learn more and be better, either explicitly or implicitly.

4. Kindred Spirits
The journey to becoming a master craftsman can sometimes be a lonely one depending on the people who work with you and the work culture that you’re in. It is very disheartening if your efforts to learn new tools, or languages or platforms isn’t supported by your manager just because “it’s the company mandate that we only use X, Y, Z products and open source tools aren’t allowed“. You need to surround yourself with people who are like-minded about learning and that can be achieved via user groups, mailing lists, etc.

My kindred spirit is in the form of Mark Needham, who is a friend and a coworker at ThoughtWorks. We discuss about everything from what’s the best build tool to use in the .Net world, to why is it so hard to change the way people work. He is constantly challenging me to explore things further like diving into the code for Rhino Mocks to understand how things are done behind the scenes.

5. Expand Your Bandwidth
You have built up a set of skills. You are comfortable doing what you’re doing now and hope things doesn’t change so you don’t have to set foot in unknown territory again.

It’s easy to get comfortable with what you know and ignore what you don’t. But unless you want to do the same thing over and over again for a long time (which is quite impossible in software development these days), there will always be new languages to learn, new tools to use, new methodologies to get used to. I don’t think we can afford to rest on our laurels in the software development world. Things change so frequently and there is always so much to learn.

Tip: Read books, read blogs. Read, read, read.

Other patterns that I think are useful:
6. Breakable Toys – use your favorite tools to build a simple application of your choice. Most work environments don’t allow for failure and experiments so you need to create a safe environment where you can do just that.
7. Use The Source – Seek out code and read it. A lot of the tools we use nowadays are open source so the code is readily available.
8. Record (and Share) What You Learn – I use this blog as a tool to record my learnings and as a platform to share them with others and to solicit feedback from them.

I highly recommend this book to anyone who is seeking to learn how to improve their skills as a software developer.

Book Review: Getting Real: The smarter, faster, easier way to build a successful web application

Getting Real: The smarter, faster, easier way to build a successful web application by Jason Fried (@ 37signals.com)

It was a little annoying that I only found out about this book 3 days ago considering that it came out about 4 years ago. Granted I was still an ignorant college kid trying to graduate back then, it still doesn’t excuse the fact that I haven’t heard or read about it at all till now. I like how the tone of the book is extremely direct and in-your-face. The guys at 37signals talk about how they build software with as little people and resources as possible but are still able to produce stellar results, in terms of customer satisfaction, revenue generation and happy employees, just to name a few.

I have been privileged (or not, depending on how you see it) to have been on projects that have made many of the same mistakes that the book points out. Making mistakes is a good thing. The trick is to actually learn from them. Teams like the one at 37signals have figured out certain practices and behaviors that work for them. Reading about them has been a breath of fresh air, that there are people out there who care about what they do so much that they are bold enough to step out on a limb to take steps that others would deem foolish and even bolder to talk about them in public.

Here are some of my favorite parts.

We believe software is too complex. Too many features, too many buttons, too much to learn. Our products do less than the competition — intentionally. We build products that work smarter, feel better, allow you to do things your way, and are easier to use.

Don’t get huffy if you read some of our advice and it reminds you of something you read about already on so and so’s weblog or in some book published 20 years ago. It’s definitely possible. These techniques are not at all exclusive to 37signals. We’re just telling you how we work and what’s been successful for us.

Build Less
Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

Launch on time and on budget
If you can’t fit everything in within the time and budget allotted then don’t expand the time and budget. Instead, pull back the scope. There’s always time to add stuff later — later is eternal, now is fleeting.

Ignore Details Early On
Don’t worry about the size of your headline font in week one. You don’t need to nail that perfect shade of green in week two. You don’t need to move that “submit” button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.

It’s a Problem When It’s a Problem
Do you really need to worry about scaling to 100,000 users today if it will take you two years to get there? Do you really have to hire eight programmers if you only need three today? Do you really need 12 top-of-the-line servers now if you can run on two for a year?

Make Opinionated Software
Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit. The best software has a vision. The best software takes sides. When someone uses software, they’re not just looking for features, they’re looking for an approach. They’re looking for a vision. Decide what your vision is and run with it.

Build half a product, not a half ass product
Beware of the “everything but the kitchen sink” approach to web app development. Throw in every decent idea that comes along and you’ll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass.

Start with a No
Each time you say yes to a feature, you’re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature’s out there, you’re stuck with it. Just try to take a released feature away from customers and see how pissed off they get. Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club.” You should only consider features if they’re willing to stand on the porch for three days waiting to be let in. [This is probably my favorite part of the book]

It’s a very fast read. 16 chapters, 91 essays and each essay is never longer than a page scroll down. I blazed through 13 chapters in 2.5 days. I think this book ranks as one of my favorites next to Uncle Bob’s Clean Code.


Book Review: Adrenaline Junkies and Template Zombies

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior
Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior

If ever you were to crave for a book that lists almost every single project behavior pattern you’ve seen in your X years of software development projects, you have found it. That might be a bit of an exaggeration, but this book definitely hits home for me on a lot of the patterns that it outlined. Here’s a list of some of my favorites.

1. #36 Cider House Rules – Members of the project team ignore or work around rules made by people who are unconnected to the project’s work

This is very typical of many large corporations. Here’s a tangible example of this pattern. Company A has a team of about 50+ developers spread across multiple teams. There is also an ‘over-arching’ team that manages the tools that the developers use. The Over-Arching Team recommends (but in effect, mandates) and supports only IBM products like WebSphere, ClearCase, RAD, etc and demands that all use of open-source software be reported to them before they are allowed into the shared Maven repository. The developers find it extremely frustrating to use ClearCase for obvious reasons but has had to fight multiple battles with The Over-Arching Team just to get them to agree that Subversion is a much more efficient tool, even though they have agreed to manage nightly check-ins to ClearCase themselves. After 6 months, the team is still struggling with ClearCase’s inability to do simple things like merge code or move at a reasonable speed. Developers are now afraid to check-in for fear of having to merge their changes in or break the build for one reason or another.

Software teams should be empowered to make decisions and rules for themselves without interference from external parties. The people who understand a project the most are the ones who are in its guts every day. It is only fair that they get to decide what tools they want to use or how to split work up between themselves to ensure they are using their time and resources most efficiently.

2. #21 Soviet Style – The delivered product has the functionality requested by its customers, and yet it is disliked and soon discarded.
#26 Straw Man – Team members feel comfortable offering a straw-man solution in order to elicit early feedback and insight.

These two patterns are related in such a way that one could be used as a solution for the other. Many organizations breed the creation of silos amongst their departments and most times the developers are just handed a list of specs and are put in a far, far away room and not given any interaction with their end users (Office Space and IT Crowd come to mind). Sometimes the separation isn’t that extreme, but there is still an imaginary wall between developers and users. We need to create a safe environment in which there can be a clean flow of communication between them. In the projects that I’ve been on, we typically schedule a show-case every iteration and invite everyone who is interested in the application we are building. The purpose of that meeting is to showcase, as the name of the meeting clearly states, whatever that has been built so far and get feedback from the appropriate sources (be it end users or business stakeholders).

I’m more than halfway through this book and it has been quite good so far, entertaining at times.

Book Review: Working Effectively with Legacy Code – Chapter 6

Working Effectively with Legacy Code (Robert C. Martin Series)

 

 

 

 

 

Working Effectively with Legacy Code by Michael Feathers

I’ve been carrying around this book with me for the past few weeks and I find myself going back and reading parts of a chapter again and again, trying to soak in the concepts. This particular chapter, titled: I Don’t Have Much Time And I Have To Change It, struck me specifically when Feathers starts out talking about change and how often it happens in code bases and that steps should be taken to make every consequent change easier than the one before. When teams make it a point to only introduce changes to the code only if they have tests to cover that change, they find that their velocity slows down and people feel like they aren’t getting as much done as they need to. Feathers emphasizes that this is normal but if they persevere, they slowly realize that they are revisiting better code and changes get easier and easier to make.

I think that it’s important for teams to understand the benefits of testable code and how it eases the process of change so that they will invest the time and energy needed to get the code to that point. And I quote:

Ultimately, testing makes your work go faster, and that’s important in nearly every development organization.

Having code that is testable is only possible if we do one of the following (If I remember correctly, I think this is according to Uncle Bob):

  1. Write the tests before writing the code
  2. Design for testability

Doing the latter isn’t easy, and in fact it is so hard to achieve that people end up not doing it at all. So that leaves us with Option 1. But sometimes you come across code that doesn’t have any tests AND doesn’t look like it is testable, but you have to make some changes in a short amount of time. So what do you do? Michael Feathers suggests 4 approaches, and my colleague Mark documents it in a short and sweet way (basically he beat me to writing the post first).

  1. Sprout Method
    Advantages: Separating new code from old code. New code is testable.
    Disadvantages: You’re giving up on the old code for now.
  2. Sprout Class
    Advantages: Allows you to move forward with more confidence.
    Disadvantages: Conceptual complexity – moving new code into a separate class disrupts the flow of how key classes in the code base work together.
  3. Wrap Method
    Advantages: A great way to introduce seams (this is a concept that Feathers talks about in a previous chapter, which we will visit in a later post) while adding new features.
    Disadvantages: This method requires you to rename the method that you want to change, and create a new method with the same name as the previous method before the rename was done. Sometimes this could introduce sloppy method names because we needed to do some renaming to make way for the new method.
  4. Wrap Class
    This method is pretty much the same as Wrap Method except you’re extracting new behavior out into a new class. Feathers mentioned that 2 things push him towards choosing to use Wrap Classes and one of them is when a class has grown so large that he cannot stand to make it worse. Pushing behavior into a new class when the existing class is unmanageably large could also indicate that the original class might have too many responsibilities and thus needs to be gutted.

I like this chapter because it formalizes a lot of things that I try to do very often because of the large range of code bases that I work with, but find it difficult to nail it down to something that could be explained to someone else.

Book Review: Lean Software Development – Build Integrity In

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

Chapter 6: Build Integrity In

What I Learned

  1. Perceived Integrity is affected by the customer’s whole experience of a system: how it’s advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. The measure of perceived integrity is roughly equivalent to market share, or mindshare. If you had to rebuild your computer tomorrow, how many products would you load? If your bookmarks were wiped out, how many would you add back immediately?
  2. Conceptual Integrity means that a system’s central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness. Conceptual integrity is a prerequisite for perceived integrity.
  3. The key to achieving integrity is through detailed information flow, from customers and user to developers and between the upstream and downstream processes of the development team. In line with the Agile Manifesto – Individuals and interactions over processes and tools, Customer collaboration over contract negotiation.
  4. Refactoring and continuous improvement is of utmost importance. This is a tribute to Pat Kua after he complained that I missed out that part in my review of Clean Code. No code (or product, or practice) comes out perfect the first time we write it. We start with something that works, learn from its weaknesses, and improve on it. Pat talks about the red-green-refactor practice in TDD (Test Driven Development) which is basically starting out with a failing test (red), making it pass (green) and then making the code better (refactor). This practice can also be extended to be applied to iterations, where we have retrospectives (refactor) to figure out how we can do things better in the next iteration, etc.
  5. Testing – my favorite software topic of all times. Developer tests assures that the code does what the developer intended it to do. This includes unit, system, integration tests, etc. Customer tests assures that the system will do that customers expect it to do, and are run throughout the development, not just at the end. Customer tests are sometimes also known as acceptance tests. So why are tests important? Why are some people so obsessed about thoroughly testing a class or a feature? And why should they be run throughout the entire development process and not just at the end? Wouldn’t it be better if we dedicated a 50-person team of testers for 3 months after the development is done? Tests are invaluable because:
    1. They unambiguously communicate how things are supposed to work.
    2. They provide feedback on whether the system actually works the way it is supposed to – and we would ideally want this feedback as soon as possible, not at the end of the project.
    3. They provide a scaffolding that allows developers to make changes throughout the development process – I recently just bought Michael Feathers’ Working Effectively With Legacy Code (and I’m quite excited about it) and read the chapter on Testing and he says that tests act less like a safety net to catch you when your code goes bad, and more like a cloak that wraps around the code and keeps bad things from seeping out to other parts that you’re not currently changing.

    If you are running tests manually anyway, going through the motions of making sure the system still works as it should every time you change a piece of code, wouldn’t it be great if we could turn those motions into a test and build a test suite that gets automatically run every time we check in? It turns out, we can!

Book Review: Lean Software Development – Eliminate Waste

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

I picked up this book wanting to know what the hype was about Lean and how its principles can be applied to Agile software development in general.

Chapter 1 Eliminate Waste

What I Learned:

  1. Anything that does not create value for a customer is waste.
  2. Learning to see waste.
    The 7 Wastes of Software Development.

    • Partially Done Work – e.g. Writing requirements for stories that might or might not be played in the near future.
    • Extra Processes – How much paperwork is necessary? A good test for paperwork is to see if there is someone waiting for what is being produced. Consider writing customer tests instead of requirements.
    • Extra Features – Developers have the tendency to want to write cool code, just in case. But extra code means extra effort for maintainability, it increases complexity and is also a potential failure point. Code that is not used could also become obsolete
    • Task Switching – Dividing someone’s time between a project management role on one project and a developer role on another project seems like a time-saving move. But would that guarantee each project to finish within their timeframe?
    • Waiting – Delays are common in many software development environments. But does that mean it is okay for delays to happen? Delays keeps the customer from realizing value as quickly as possible.
    • Motion – When a developer has a question, how much motion does it take to find out the answer? Various artifacts move as well and each handoff of an artifact is fraught with opportunities for waste.
    • Defects – These are inevitable in software development but waste caused by a defect is the product of the defect impact and the time it goes undetected.

    3. Value stream maps show that non-development activities are the biggest bottlenecks in a software development value stream.

I do sometimes go about activities just for the sake doing them but rarely find the time to step back and assess whether it’s valuable to the customer or if I’m wasting time. Keeping an eye out for waste is a good tool to have and is related to a previous post of mine about delivering business value.

Book review: Clean Code: A Handbook of Agile Software Craftmanship

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series)

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin

My friend and colleague, Mark, lent me this book about 9 months ago and I’ve been slowly reading (ok, i’ve been slacking off for a few months) through it but I’ve finally made it to the end (well, sort of the end). I’ve been learning a lot of the things that were mentioned in the book over the course of the past few years working with my talented colleagues at ThoughtWorks but I think Uncle Bob (and friends) did a very good job of nailing down the practices that help developers write clean code. The book uses a lot of examples and shows a lot of code as well. I would recommend it for any developer who would want to improve themselves and learn how to write better and cleaner code.

What I learned

What is Clean Code? Uncle Bob asked some very well-known and experienced programmers what they thought and almost all of them agree that clean code should be straightforward, easily understandable and does ONE thing well.

Meaningful Names
The first step towards straightforward code is to have names that clearly reveal the intention of the author. That includes variable, method and class names. A name should answer all the big questions: why it exists, what it does, and how it is used. For example:
int d; // elapse time in days

The name d reveals nothing. We should choose a name that explicitly says what it represents:
int elapsedTimeInDays;

Functions
Functions should be small. They should do one thing. They should do it well. They should do it only.

In order to make sure our functions are doing only one thing, we need to make sure that the statements within our function are at the same level of abstraction.

The ideal number of arguments for a function is zero but one or two are acceptable. Three arguments should be avoided where possible, and more than three should require a very special justification else shouldn’t be used at all. Passing a boolean into a function is a bad practice. It immediately says that the function is doing more than one thing because if the flag is true, it does one thing, if it’s false, it does another.

Error handling should be done separately, because that’s already doing ONE thing.

Comments
I have always hated code inlined with comments (after of course I learned that my code should serve as the one and only documentation). It complicates the code because one would have to read the code AND the comments and if they don’t match up then it will cause more confusion.

Objects and Data Structures
This was an interesting chapter that outlined the difference between the two entities, which I thought were interchangeable. Objects hide their data behind abstractions and expose functions that operate on that data. Data structures expose their data and have no meaningful functions. They basically are virtual opposites.

This also highlights the differences between procedural and OO code.

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.

This is not to say that we never want to have data structures, but I think we just need to be careful when creating our “objects” and make sure that they aren’t data structures in sheep’s clothing.

Error Handling
I’ve been learning more about this topic recently, especially in one of my previous projects where error handling was of utmost importance since we were writing a shared services tool. It’s important to know when to throw exceptions and how to catch and handle them properly. Here are a few pointers from Michael Feathers:

  1. Use exceptions rather than return codes
  2. Write your try-catch-finally statement first
  3. Use unchecked exceptions
  4. Provide context with exceptions – to determine the source & location of an error
  5. Define exception classes in terms of a caller’s needs
  6. Don’t return null
  7. Don’t pass null

Unit Tests
If there could only be one important thing to software development, testing would be it. But sadly a lot of developers treat tests as an after-thought, but really when we’re manually firing up the application and clicking a bunch of buttons to see if something was working, we could automate those steps and voila! we have a test!

The next step would be to drive the code from the test. The Three Laws of TDD (Test Driven Development):

  1. You may not write production code until you have written a failing unit test.
  2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  3. You may not write more production code than is sufficient to pass the currently failing test.

Classes
I wrote a post about this chapter previously. You can read it here.

Systems
To stay clean a a higher level of abstraction, we need to be able to separate the construction of a system to it’s usage. There are a few ways that we can achieve that, the most primitive being moving all aspects of construction to the main method. Other ways include using factories and dependency injection.

Chapter 17 lists the code smells and heuristics that Uncle Bob has encountered over the years.

All in all a very useful book!

Book review: Predictably Irrational: The Hidden Forces that Shape our Decisions – Part II

Predictably Irrational: The Hidden Forces That Shape Our Decisions Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely

The High Price of Ownership

Why do things become more valuable after we own them? Why do we think that the 10 year-old couch that we are trying to sell is worth $200 when someone else wouldn’t pay more than $30 for it? I won’t be able to phrase it more aptly than Dan does:

Ownership pervades our lives and, in a strange way, shapes many of the things we do. Adam Smith wrote, “Every man [and woman] … lives by exchanging, or becomes in some measure a merchant, and the society itself grows to be what is properly a commercial society.” That’s an awesome thought. Much of our life story can be told by describing the ebb and flow of our particular possessions – what we get and what we give up.

The 3 irrational quirks in our human nature:

  1. We fall in love with what we already have.
  2. We focus on what we may lose, rather than what we may gain. Our aversion of loss is a strong emotion.
  3. We assume other people will see the transaction from the same perspective as we do.

Keeping Doors Open

Now this plagues me personally more than anything else. I’ve been finding it hard to put my roots down but I feel as though I would be missing out on life if I did. FOMO – Fear of Missing Out.

What is it about options that is so difficult for us? Why do we feel compelled to keep as many doors open as possible, even at great expense? Why can’t we simply commit ourselves?

Wouldn’t it be nice to have a built-in alarm, to warn us when the doors are closing on our most important options?

Dan suggests that we need to start closing the doors ourselves. Start with smaller doors, then move on to bigger ones.

But the bigger doors (or those that seem bigger) are harder to close. Doors that just might lead to a new career or to a better job might be hard to close. Doors that are tied to our dreams are also hard to close. So are relationships with certain people – even if they seem to be going nowhere.

I’m leaving out the last 5 chapters because there’s just too much I want to point out. But you should pick up this book, for yourself, or for a friend. It points out a lot of things about the human nature that we take for granted but if we start noticing them we might be able to make our lives a little easier, a little less complicated, possibly a little better.

Book review: Predictably Irrational: The Hidden Forces that Shape Our Decisions – Part I

Predictably Irrational: The Hidden Forces That Shape Our Decisions Predictably Irrational: The Hidden Forces That Shape Our Decisions by Dan Ariely

I had run out of good, engaging books to read until a dear friend of mine, Sonia, gave me this as a gift.

Semi-paraphrase from the book:

Standard economics assume that humans are rational beings; that we have all the information about our decisions, and we are able to discern the value of the different options that are before us and consequently able to weigh the pros and cons of each option before making our decision. Even if we were to make a wrong decision, standard economics suggests that we learn from our mistakes very quickly on our own or with the help of “market forces”. This is how conclusions are drawn about everything from shopping trends to law to public policy.

Interesting? Read on.

What I learned.

Everything is relative
Life sometimes involves a lot of comparison. We compare who has the biggest pencil case when we’re in elementary school. We compare grades when exam results are out. We compare which family goes for the coolest vacations. We compare colleges to decide where we want to spend the next 4 (or 3 or 5) years of our lives. We compare student reviews of Advanced Graph Theory and Computer Graphics I to decide which class to take for our senior year. We compare job benefits when we graduate to decide how our career would start out. We compare looks, family background, job and car of the two guys who have been calling us to know which one to give a cold shoulder to when they call again. But as it turns out, everything is relative. It becomes a problem when we look at our decisions in a relative way and compare them locally to the available alternative.

One way to curb this problem is to control the “circles” around us, moving towards smaller circles that boost our relative happiness. Author Dan Ariely suggest this: if we are thinking of buying a new house, we can be selective about the open houses that we go to, skipping the ones that are beyond our means. If we’re thinking of buying a new car, we can focus on the models we can afford, and so on.

Another trick is to take a broader perspective on things, which is not always easy. Consider this example, you need to buy a new pen and a new suit. You go the nearest office supply store and see that the pen that you want is $25, you almost buy it when you see a flyer for the same pen that’s sold in a store 15 minutes away for only $18. Would you spend 15 mins of your time to save $7? Most people would.

While shopping for your suit, you find a nice one for $445. But a guy who was browsing next to you whispered that another store is selling the same suit for $438, but that store is a 15 minute walk away. Would you make the trip to save that $7? Most people wouldn’t.

What’s going on here? It should be irrelevant if you were saving $7 on a $25 purchase or a $445 purchase, after all, it’s still the same $7.

The Fallacy of Supply and Demand

Arbitrary Coherence is the idea that although initial prices are “arbitrary”, once those prices are established in our minds they will shape not only present prices but also future prices (this makes them “coherent”).

Price tags themselves are not necessarily anchors. They becomes anchors when we contemplate buying that product or service at that particular price. We are influenced by anchoring in every choice that we make, whether or not to buy a certain blend of coffee, whether or not to go to that jazz concert, whether or not to live in the suburbs, whether or to vote Republican, etc. Standard economic theory says that we make these decisions based on our personal preferences, our likes and dislikes. But could it be that our lives are so carefully crafted in such a way that we are just a product of Arbitrary Coherence?

In a similar manner, claims of free market and free trade don’t really make sense if our choices are affected by random initial anchors.

The Cost of Zero Cost

If I set up a table on the street and sell you 2 kinds of chocolates: Lindt chocolate truffles for 15 cents, and Hershey kisses for 1 cent, which would you pick? If I were to change the prices to 14 cents for the Lindt truffles and give away the Hershey kisses for free, which one would you pick now? The only caveat in both cases being that you are only allowed to choose ONE piece of chocolate. The power of FREE! is amazingly strong.

The Cost of Social Norms

This is by far my favorite chapter of the book.

We live in a world governed by 2 sets of norms, social and market. The social norms include the favors we do for our friends/family and the people around us. Can you help me move my couch? Can you take the mail in for me? Can you pick up my kids from school tomorrow? These are driven by our need for community and instant payback is not required. Market norms are defined by sharp-edges exchanges: rent, buy/sell, wages, interest, etc. What happens when these two worlds collide?

You are at your mother-in-law’s for Thanksgiving and she has just made an incredible spread for the family, complete with turkey, gravy, stuffing, cranberry sauce, green bean casserole and cherry cobbler for dessert. You feel extremely stuffed and slowly sit up from your comfortable armchair, reach into your back pocket and pull out your wallet. “Mom, for all the love that you put into this, how much do I owe you? Would $300 be enough? How about $400?”. Imagine the after-math of that question.

The Influence of Arousal

Would we be inclined to do the things we say we will never do when we are in an impassioned state than when in dispassionate circumstances? Do we throw logic and rationale out the window when we are emotionally or mentally aroused (angry, frustrated, hungry, annoyed, etc)? The answer, scarily, is yes.

The Problem of Procrastination and Self-Control

25 years ago, double digit savings rates were the norm in America. In 1994, the number was 5%. By 2006, it had fallen below 0 to -1%! Europeans do a lot better, they save an average of 20%, Japanese save an average of 25%. In China the rate is 30%. What’s going on with America?

One problem is that Americans have succumbed to rampant consumerism. But the other explanation is procrastination. The promises to save, to exercise and watch our diet all go up in flames when we see a new car, new bike, new pair of shoes, a delicious looking slice of chocolate cake, or that strawberry milkshake.

Not everyone understands their tendency to procrastinate, and even those who recognize their tendency to procrastinate may not understand their problem completely. People may set deadlines for themselves but not necessarily deadlines that are best for getting the best performance.

To be continued…

Chapter 6 – Leadership as Orchestration

Women on TopWomen on Top by Margaret Heffernan

A colleague of mine, Sumeet Moghe, recently talked about how the job of a project manager was two-fold; managing the project and leading the people and how important it was for a leader to invest in the team and help them grow. “As a great manager, one should be able to develop people and accomplish results at the same time”. Productivity does not equal to busyness.

I whole-heartedly agree. Rhymes very well with what I’ve been reading here in this book.

This chapter sings the praises of people who have been able to redefine the face of effective leadership. They are proving that the command-and-control corporate model will not suffice anymore in the 21st century.

Great leadership is about:

  • putting the right people in the right place
  • enabling people to perform to their fullest potential
  • teaching people – by coaching, by goal-setting, by example – how to collaborate effectively
  • unleashing the ability of others

We have to come to grips that success and excellence in this modern economy can no longer be about one-man-shows and solo acts. As Heffernan puts it:

The forces operating on any single company are now too numerous, too complex, and too fast moving for any individual leader to master.

There might have been a time when one person could do it all and rule the world, but in this current fast-moving world, there is constant and frequent demand for innovation and it’s impossible for one person to know it all.

… so leadership becomes about building functional teams that can. It is about harnessing what James Surowiecki would call the wisdom of crowds (italics mine).

Groups of people working together make better decisions than single individuals – but that delivers diversity only if the individuals in the group are different, are allowed to remain different, and are allowed to be honest.

Brenda Rivers, CEO of Andavo Travel, puts it this way:

“It’s like kayaking. Servant leader, that’s me. I lead from behind, and I hold the rudder. I make sure everyone is fit, encouraged, and enthused, and knows that we will get through.”

And I leave you with the end of this chapter’s closing paragraph (and have bolded my favorite parts):

We are not dominant, which means that we aren’t threatened when our employees know more than we do. We are collaborative and understand that part of being collborative is knowing when to bite our lips. By not singing our own praises, we leave space for more than one hero in every company. By not hogging the spotlight, we let whole teams shine. Only an idiot (italics mine) would mistake this for weakness.