The Model

I don’t use Quicken or Microsoft Money for keeping track of my finances. Since 1997, I use some software that I developed myself and which I call “The Model” for doing this and it has worked very well for me in all of that time.

I am about to start down the road of doing the first major revision to this software in several years, adding in some new features and making some efficiency enhancments.


I originally developed the application as a way of helping us decide how best to use Tawnya’s student loan money that she received back when she was in graduate school. The idea was to reduce stress by projecting every single bill, payment, and income that we paid or received into some point in the future so that we could see what our financial state would look like 2 months from now, or two years from now. It also made it easy to see what wouldn’t work.

It evolved from here into a system that tried as much as possible, to show what things would look like, simulating or “modeling” (thus “The Model”) a financial situation from a starting point to a particular end point. The starting point involves entering all of your bills (how much, how frequent, due dates, etc.), all debts (how much, how frequent, APRs, due dates, etc.), all income (how much, how frequent, etc.). It also involves some simulation settings: inflation rate (bills can increase over time), compounding interest rates, etc.) Finally, it runs in two modes: savings or debt mode. Debt mode tries to pay off any debts as quickly as possible, savings mode tries to save as much money as possible. Later versions of The Model allowed you to switch from one mode to another using “rules”.

The central concept of the software is what I call “current extra payment”. This concept has evolved quite a bit over the 9 years I’ve been developing and using the software. At present, current extra payment is the amount of money left over between two consecutive paychecks, once all payments (bills and debts) have been accounted for. For instance, if you get a paycheck for $500 on Thursday and on the 8 days later, your wife gets a paycheck for $550 then the system projects (using the starting point information) the total number of bills and debts you pay out in the 8 days between the two paychecks. Assuming there is money left over that is considered “current extra payment” and is applied either to savings or paying extra money on debt to get it paid off quickly.

Current extra payment is essential but there are other important parts of the system that evolved over the years. “Overdraft protection” is one. This started out as a way of preventing bounced checks. If the system detects a negative balance, it would recommend a course of action, such as transferring $X from a savings account to a checking account to prevent the overdraft. The output of The Model is kind of like a bank statement, listing all of the transactions that will take place and it would insert this “overdraft protection” transfers into the register so that if you were checking up on it day-to-day and following the recommendations, you wouldn’t have a problem. In the 2003 version of the application, I took this to a new level, using model iteration runs to avoid overdrafts at all. Now The Model runs until it gets an overdraft. When it does, it stops running, records how much it was overdraft by and when, and then restarts, using that information to reduce savings amounts or extra debt payments so as to completely avoid overdrafts. (Of course, in dire situations, it still runs into them and if you get the numbers right, you can force negative balances, but that’s the real world for you.)

Visual Basic version considered taxes as well and provided simulated estimates for tax bills (or refunds). It also can simulate the purchase of a house down to a very detailed level (more than just mortgage payments, but it factors in downpayments, property taxes, PMI, etc.)

As I said, you run a “model” and the output that is produced is a table that tell you when to pay each bill and how much (estimated of course based on your starting point). It shows running account balances, debt balances, retirement balances, tells you how much to put into savings, how much to pay on a credit card, etc. You have to be disciplined and review the table every day. Reality and the model often don’t match, but if you are disciplined, they can be pretty close. We were able to pay off our cars years early and pay off all debt but student loans by using this software.

This software started out in its earliest incarnation as a macro-enabled Excel spreadsheet. From there it quickly became a Visual Basic program, going through several iterations. Back in 2003, I ported the application to UNIX, making it into a set of object-oriented perl scripts. The next step in the evolution of The Model is a big one for me. I am porting it to xcode for the Macintosh and using Objective-C for the first time in my life. I figure it’s as good a way as any to learn a new language.

  • Real-time tracking. Data will be stored in a MySQL database and the system will allow you to track actuals next to projected values. It will then compute differences and tell you how much you are off from the model each month (or week, or year).
  • Projection efficiencies. Right now, the model simulates every single day, whether or not there is any activity. My estimation show, however, that there is activity on only about half the days in a month. The program can be made much more efficient by building an index of days to process based on an algorithm that tells you whether a given day has activity and storing that date in the index. Interest calulations can then be made by normal compound interest functions, rather than daily summations. This should at least double the speed at which the application runs.
  • Savings buckets. This is the idea that certain budget categories can be stored as savings buckets within an account. For instance, I allocate $X for travel each month. If I don’t use it, it becomes hard to know how much of the money in that account has been allocated for travel versus other things. The “savings buckets” will keep track of this, indicating that I have $Y worth of accumulated travel money in the account.
  • Re-institute tax calculations. I took these out when I did the perl versions but I’m going to put them back in as part of the xcode version.
  • User interface. The current “interface” for the application is a “text” field written in a kind of macro language that describes the starting point for the simulation. While I like this because it’s easy to manage, I also want to have this information updatable by a nice user interface. In the first xcode iteration, I’ll stick with the text file, but future versions will also have a Cocoa interface for the application.
  • Universal binary compatible. Eventually, I’ll get a MacBook and I’ll want the code to run on Intel-based processors.
  • Algorithm improvements. Better math. A lot of what I do is driven by the day-to-day iteration of the model but single calculations will be much easier and more efficient. This involves algorithms that can do summations and limits, but these can almost always be expressed as functions. It just means I have to go back to the calculus text books and remind myself how this works.
  • Improved “rules” language. The Model supports a mini-language for defining simple rules. A simple rule might be: When Savings Account > 10000 Then Debt Mode = 1 (when you’ve saved $10,000, then go ahead and stop saving and instead start paying off debts). I’d like this to be more sophisticated to cover more complex scenarios.
  • What If scenarios. Allow for the randomization of what if scenarios during model runs. (E.g. what if I lost my job at a random point in time–what would the output look like?)
  • Documentation. I need good documentation. I’d like to make this freely available to anyone who wants to use it, alter it, whatever. For that I need some good documentation.

There are some more but I can’t think of them. I expect that this revamp will take 6 months to 1 year to complete (in the meantime, the perl version is working just fine). Mostly there will be a learning curve on Objective-C and that will take time, and with everything else I’ve got going, I won’t be writing code everyday. But I’ll ocassionally post on my progress.