The topic of discussion today is fallacies that effect programmers on a day to day basis, also referred to as “cognitive biases”.  A quick look on wikipedia yields us this useful description:

A cognitive bias describes a replicable pattern in perceptual distortion, inaccurate judgment, illogical interpretation, or what is broadly called irrationality. They are the result of distortions in the human mind that always lead to the same pattern of poor judgment, often triggered by a particular situation.

What does this mean? It means due to emotional irrationality you are prone to make poor judgements and decisions based on previous experiences even if the opposite outcome is better for you in the long run. Even a specific way a question is worded can make you choose opposite choices.

The first fallacy i’m going to talk about is the “Sunk Cost Fallacy”. I’m going to quote Peter  Michaud‘s post here because I really like his description

Sunk Costs are costs which have already been incurred and cannot be recovered. The Sunk Cost Fallacy is a mistake in reasoning in which you consider the sunk costs of an activity (instead of the futurecosts) when you decide whether you should continue the activity or not.

As developers we experience this problem every day while coding, the language our app is written in, libraries we are using, a particular design pattern or architecture we have chosen to use. Deep down we know this is not healthy for the maintainability of our app down the road, but yet we find it hard to scrap it and start fresh. Why is this? It all boils down to loss aversion.

loss aversion refers to people’s tendency to strongly prefer avoiding losses to acquiring gains. Some studies suggest that losses are twice as powerful, psychologically, as gains.

You see, although refactoring, or rewriting all together seems like it may be a lot of work, even though we know it’s ultimately best. It’s not the idea of that work that chooses us to continue painfully stuck in our old decisions. It’s the pain of feeling like all the time, money and resources spent on the old implementation was a complete waste, by changing to something different we have to accept the fact that we threw away all of that, it was worthless, or was it?

I really love some of the examples on You Are Not So Smart‘s article. It talks a lot about how the sunk cost fallacy and loss aversion keeps games like Farmville thriving. It’s worth the read if you can spare the extra couple of minutes. I’m going to quote an example from the article.

If you dropped your cell phone over the edge of a cruise ship, you would need James Cameron’s unmanned submarine fleet to find it again. Sure, you could spend a small fortune to retrieve it, but you wouldn’t throw good money after bad. Laid out like this, logical and rational and easy to pick apart, you can pat yourself on the back for being such a reasonable human. Unfortunately, the sunk costs in life aren’t always so easy to see. When something is gone forever it can be difficult to realize it. The past isn’t as tangible a concept as the sea floor, yet it is just as untouchable. What is left behind is just as irretrievable.

He’s right, in a situation like this the answer is clear, it’s gone, move on, but when it comes to the things we hold more dear and slaved over the decision becomes clouded.

But let’s really think about this, you replace your car every so many years, you replace warn clothes, shoes and many other things. You paid money for them, and sometimes quite a bit, but when they’ve seen their day it’s time to move on.

I’d advise that we keep this into consideration when we are deciding to deprecate whatever library, language, framework, or implementation that is no longer as usefull as it once was and is just causing more work and pain to keep stable and maintainable, just because we may feel that we wasted time and resources. The time is gone already, irretrievable. You will never get it back, and you will never get back the time you continue to poor into something that is just no longer useful.

The fact is that it was useful for a period of time, it served it’s purpose well. Pat yourself on the back for that, and then pat yourself on the back for the next rendition of it. Your time was not wasted, remember that. You performed a task to get your app to what it is today, and it was the best choice at the moment, but make sure to consider if it is still the best choice moving forward, or if it’s just going to cause you more greif than anything.

The past is irrelevant in this particular decision. What matters most is what is best for your future as well as the app / codebase. Choosing a new direction does not mean that the old choice was a bad one. It was a learning experience and something to grow on. Growing out of something is a good thing. Your users evolve, the company evolves, it grows, it adapts, and so should the code base. Your employer would not stay in the same building they invested 2 years in, and lots of money if they needed more space to accomodate all the new hires. You shouldn’t stay with the same technology decisions if the direction of your app is changing either. It served it’s purpose for the time being, and it was great. What’s next?

1) Use XDoc comments wherever applicable. There are a number of tools out there that will make your life a lot easier when generating base documentation and HTML versions of your API documentation. They are quite useful.

2) Don’t comment just to comment. Quantity is not better than quality in most situations and this one is no exception. To many comments can be distracting and take you away from what is important; The code.

3) Answer the write question. To many times I read comments that always answer the question “What?” . If you can not easily read your code and determine what its doing you may want to consider addressing the problem a different way. There are a few exceptions to this rule with complex algorithms and methods, but you should use comments that answer this question minimally. The real question that should be answered is “Why?”. 6 months or 2 years down the road when you open up the code its probably going to be fairly obvious what the code is doing, what will not be so obvious is why you did something that particular way, some business based rule that was determined in a meeting that made sense at the time, is now just a big question mark. You will thank yourself when you don’t have to rewrite something just to figure out there was a reason you had done it that way.

4) Use examples. Even the best documentation and comments can leave confusion to people not as familiar with the code as you are. Be sure to include small snippets of code demonstrating how to use a class or method that you have created if there may be room for confusion.

5) Don’t be afraid of humor. Hunting down defects or just implementing a new feature can be long and tedious at times. At 3am when you or a fellow developer are knee deep in code you’ll appreciate the laugh it will remind you how much fun coding is.