Jason M. Hanley :: Custom Software Developer

Last week I closed two accounts at Bank of Montreal. The one account was a corporate chequing account I’d had with them for 4 years. The other account was opened when I was 13 years old. It’s been active for more than 15 years.

Moving all of your financials from one bank to another is a pretty time consuming process, and not usually done unless there are significant reasons. I had several:

1. BMO wanted to charge me $500 just to apply for a corporate line of credit, whereas RBC approved me quickly with no upfront fee
2. RBC’s online banking system is better than BMO’s
3. I don’t like my closest BMO branch
4. The service fees at RBC are marginally cheaper for the number of transactions I do

The amazing thing? Nobody even asked me why I was closing two major accounts after being with them for over 15 years. The CSRs didn’t care – which means that upper management doesn’t care either.

In a normal competitive environment, a service company would be very concerned about losing a good, long-term customer. If you’ve ever tried to cancel long distance or Internet services in the States, you’ll know what I mean. Sometimes they’ll offer you several months of free service just to keep you.

The banking system in Canada is so messed up. There are 4 national banks, and they all have nearly the same account and fee structures.

You can shuffle between any of them, but they really don’t care if you come or go. They know you don’t really have much of a choice.

Estimating software development time is hard. There are so many variables, unknowns, “unknown unknowns”, and the specification always changes. Besides that, developers tend to be optimistic by nature.

Here’s a handy little way to come up with a quick, yet accurate estimate:

1. Come up with your best, overall estimate that you feel is realistic using your favorite technique, or pure “gut feeling” if you are a very experienced developer and you know the problem domain well.
2. Ok, you have your absolutely realistic number now, right?
3. It’s not realistic. I guarantee you there are aspects you haven’t thought of. Double the number. This is your best case scenario estimate. This is how long it will take assuming everything goes well and there are no snags or major changes along the way.
4. Now double it again. This is your most likely estimate. This is how long the project will probably take, when all is said and done.
5. Now double it a final time. This is your worst case scenario. If things go really badly, or you run into several major issues, it could take as long as this.

So to sum up:

• E = Your best original time estimate
• 2(E) = Best case scenario time in reality
• 4(E) = Most likely time in reality
• 8(E) = Worst case scenario time in reality