Financial Planning and OOP

Financial planning can and probably should be more like Object Oriented Programing (OOP.)

Much of life is object oriented.  For example when you write a check, the check clearing object appears.  The object expects certain well-defined inputs.  Date, amount, payee, account number and payer.  There are boxes for each.  The output is narrow.  Transfer money to someone else.

In OOP, there are objects or modules as you would suspect.  Like the check clearing object.  They are packets of code that perform some task.  Maybe input a key stroke,  send information to a print buffer, calculate a sum, or display on a screen.  The programmer can disconnect from the main logic of the program and do the modules separately or they can delegate those tasks.

In any program or plan there is a chain or reasoning that deals with the task from start to finish.  Maybe calculating the trajectory to send a scientific package to Mars or do the payroll.  The chain of reasoning aspect appears in financial planning.  The chain is the task of allocating money you earn today to the government, the present, the past, and the future.

In financial planning, the client must create the general logic chain.  Who, What, When, Where, With what?

The advisor has two roles.

  1. Check for missing pieces or logical contradictions.
  2. Create objects that will allow the program to execute.

Objects are efficient.  The client needs to know inputs and outputs but not the processing method.  Treating an object as a black box provides value:

  1. The client can focus on the areas that truly matter to them and within which they have the necessary skill and insight.  They need not know or care about completing specific tasks.  Knowing the inputs and the expected outputs, they can focus on the master task.
  2. Using objects allows effective delegation.  There are usually several ways to address a particular problem.  Without any technical knowledge or skill, the client can choose among objects.  The selection can recognize priorities and limits.  Cheaper solution for now, fix it up later.
  3. Objects are maintainable independent of the master program.  In old software a change in one place could have unexpected outcomes somewhere else.  As long as inputs and outputs don’t change, objects remove that risk.
  4. There is little advantage to knowing a great deal about a decision that you may make just a few times.  There is even less advantage to know a great deal about a task where the rules change frequently.  Delegate the How.

Life insurance, disability insurance, fire insurance, investment funds, RRSPs, wills, powers of attorney, bank accounts, credit cards and mortgages are all objects.  They are tools that execute the master plan.

Financial plans that form as a collection of objects without the chain of reason are failure prone.  Tools should have no existence in your reality except in context of a particular problem or opportunity.

The rule is simple.  Decide what you are trying to accomplish before you decide how to go about it.


Don Shaughnessy is a retired partner in an international public accounting firm and is presently with The Protectors Group, a large personal insurance, employee benefits and investment agency in Peterborough Ontario.

This entry was posted in Personal Finance, Planning and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s