Saturday, April 18, 2009

Logical fallacies and software

Logical fallacies are simply arguments that sound logical. The books you can find on the subject are usually aimed at winning arguments or rather to avoid loosing an argument to a purveyor of false arguments.

Software usually fails from logical fallacies... I can tell by your expression, you are intrigued, but not convinced. Poor logic kills software, but why say logical fallacy as if it is different?

Lets take a simple one. Look at two statements. 

  1. If I break an egg with a hammer, the egg was broken by a hammer.
  2. If the egg is broken, I broke it with a hammer.

Version 1 is a valid argument. Version 2 is not. Version 2 is actually influenced by version 1. We assume hammers can break eggs, so all eggs are broken by hammers. The fallacy is assuming that prior evidence leads to statements of truth in the future. In fact, it is accident that 1 lead to the assumption in 2. The second egg could be broken in various ways from simply dropping it, to an earthquake, a hatching chicken, to being run over by a steam roller or hit by an asteroid from space. 

Version 2 is only likely to be true if the egg lives in a hammer factory. But as you can see, just because you are in a hammer factory, not all eggs are nails.

Look at a real world example:

  1. If I try to break into a computer and fail, I will fail to enter the password three times.
  2. If the user fails their password three times, they are a hacker.
Again, the first statement leads to the false assumption in the second statement. Just because a hacker needs to guess a password, a real user might goof three times, but we assume they are a hacker.

The danger here is assuming that messing up a password is the action of a hacker. Is it? Odds are, so. Most people forget passwords, mistype passwords, or even use the password for another application by mistake. It is easy to test too.

Failure to enter a password is not proof that the user is a hacker. But many developers treat these poor people as villains. I'm fairly sure you are a victim? Have you ever had to go through hoops to reset an account that is locked down because you goofed your password?

This is just one fallacy. There quite a few that lead to issues with poor application logic and assumptions. Read up on logical fallacies. Be a better developer by knowing the difference between good logic and a fallacy.

Here are a few good books:








 

Friday, April 17, 2009

Use Your Brain

Your job is to use your brain. Not just to think. You need to learn, imagine, be creative, and think.

Put yourself in the user's shoes. Don't think of what you want, but what the user needs in specific situations. Use your imagination. Study the subject. What works? What does not? Think through usage scenarios to test your assumptions. What can we do that is new? If I have a set of ingredients. how can I mix them in new ways?

Today I talked with a high ranking officer in the US Airforce reserves. He has been on the job for 25 years. He praised me for understanding his problems and amazed at my creative and on target insights and solutions. I have many experiences like this. Why? Have I been in his shoes? Have I flown a plane? Have I been in battle? No, but when I have a customer, I study their domain. 

I put myself in the customer's mind and imagine being in their shoes.

The true definition of an architect, programmer, or an analyst is a knowledge worker, not a robot. Knowledge and imagination are your tools. You learn the domain, talk to people in the domain, and imagine you are the user in the domain. Think of problems, their solutions, and test the solutions on paper, then implement those solutions. 

If you blindly follow a spec, you get a blind implementation. The reality is that specifications, requirements and even designs are important, but only if you use your brain on the way to the implementation. 

User requirements are from the user point of view, not how you need to implement them. They are not everything you need to think about to create a successful solution. Specs and requirements are worthless pieces paper; By themselves at least. They hold very little value by themselves. Add your brain to make them real.

Do these things and you will be successful, well paid, and you will enjoy your job.