This seemingly simple question has lot of thought behind it. It is all about metrics, what to measure, how to measure, and how to use the,. Not scientific enough, but written for motivational purposes.

How long does it take to boil an egg? (Or Total Time to Boil An Egg or TTBAN).

I am sure you all boiled eggs at some point or other. But how many of you can answer this question? Honestly.

People will say around 5 to 10 minutes.

Think about it. Suppose you are boiling an egg again. You have to look at it occasionally to see if it is done. To be cautious, you let it overcook. And, you will be forced to check on it periodically. Each of these actions say cause 2 minutes of your time. I am counting the fuel loss also in time.

Suppose, you boil an egg once a week. On average, you cook for 50 years. So, an average, you will be spending around 500 hrs because you never know exactly how much time it takes to boil an egg. Imagine getting 20 days of your life with some planning.

Now, think of how you do the "virtuous cycle": Code, Test, Debug. If it takes longer for you to test, even simple inefficiencies add up and waste time in the critical moments.

If I were a developer, I would see where I am spending my time. I will make sure that the environment and I match in my work habits.

So, lesson 1: If you are a developer, you always watch how you are working and work towards improving efficiencies.

Suppose you are a manager. How does this information help you?

Lot of managers think their duty is only these:

1. Planning the project
2. Following the plan
3. Making sure that people follow the plan
4. Planning for additional resources

If you think only these are your duties, your developers will most surely call you "Soup manager". That is when all you do is to come around and ask "is the soup done"? The question does not change the answer, obviously.

So, the egg lesson is that the manager knows where the efficiencies lie even when the developers are not aware of them. They also would know how much time each task takes so that they can verify the developer's understanding.

For example, if I were a manager, I would see where the developers are spending time. It could be as trivial as the font settings on the machine to downloading mail to opening Word Files. I would see how to improve those efficiencies.

Also, I would use my experience to assess if developers understanding of the problem is correct. If I were to ask some developer the TTBAN, and he were to answer 1 hr, I am sure there is a gap in understanding. May be he is thinking that he should get the egg from the market, or make a curry of it. Or simply he does not have enough fuel.

So, as a manager, this information would help you to assess the understanding and ability of the developer.

So, what else?

There is more. For example, if you are a senior developer, you understand that the unspoken assumptions builtin in TTBAN. If you are cooking in high altitude, it takes longer to boil. So, you would have seen it before and be alert to that. You would also know it takes different times on an electric stove vs. gas stove. Why? Because you are experienced.

So, if I were a senior developer, I would understand the assumptions in any software design. Just because somebody tells that this software works, I would not accept it at face value. I know what works in what context. I know what kind of tools to use since I know which one works where.

What next?

If you are an architect, you also would know how to change the parameters. For example, you would understand why people are trying to boil an egg. May be it is for a dinner. But you would look at the guest list and figure out that all the guests are vegetarian! So, you would change the problem completely.

So, if I were an architect, I would not immediately solve the problem without understanding the intent. I understand it and see if we are solving the right problem. If needed, I will change the problem.

Anything else?

Well, lot more. All that will have to wait for some other day.