Archive

Archive for the ‘Software Development’ Category

NOT feeding the monster

February 15th, 2011 Comments off

So it’s been over 7 months since I posted on my blog.  I suppose there’s nothing wrong with that but I had intended to post regularly.  I definitely haven’t been “feeding the monster”, which is a blogging term that means you have to blog often to get a following.  I’m not really after a following; this is just a publicly available brain dump, really.

PayDay is on hold due to paid freelance work taking precedence over the unpaid passion project.  That’s ok, though.  The good thing about a passion project is you’re doing it for yourself and you’re not going to let down anyone if you need to shelve it for a while.

I was going to post about currencies in PayDay and I started writing the article but I think I’ve overcooked the idea of currencies.  Now I don’t think I even need currencies in PayDay.  It’s meant to be a personal budgeting tool that gives you a heads up about recurring bills.  Not many people have recurring bills that are from another country.

Another thing I was missing was the idea that the act of converting currency and how it is done is tied very much to the situation.  Why are you converting the currency?  If it’s to see how much that Think Geek t-shirt will cost in AUD then you’re going to have to take that conversion with a grain of salt.  That AUD figure is just not going to be what you are going to pay for that t-shirt once the transaction is done.  The obvious reason is that the exchange rate changes all the time.  That’s obvious.  Another reason is that the financial institution that make the purchase through will charge you their own rate for the conversion.  If you get your conversion rates from xe.com I guarantee that the rate will be different to the one that your bank will use when they send the money to Think Geek.  Let’s not forget that some banks will also charge a conversion fee.

Sometimes you just need an approximate representation of that foreign currency in your local currency.  You know it’s not accurate but that’s ok, you just need to know a ball park  figure.  Then currency conversion is more about statistics; “on average how much AUD will x USD cost?”

For currencies to make sense in PayDay I would have had to add the concept of ‘approximate value’ into the model.  I think that’s a valid concept to have but I wouldn’t bake it in until a few version later.  I think, also, I’d have to have the approximate value feature done before I could think about having multiple currencies in PayDay.  I’d make it so that approximate values were applicable not only to currency conversion but to bills that you know might change in value over time, like Brisbane City public transport costs (grr!).

Anyway once I finish my current freelance work I’ll get back into PayDay.  I bought a MacBook Pro a few months ago so I’ll have to get PayDay up and running on that.  I want to keep it as a .Net project so I might have to install Windows 7 on the Mac or wait for MonoMac.  Mac Zealots please don’t write in abusing me 😉  If it’s all too hard to get a working .Net environment running on my Mac I might change the the project’s technology stack but I’d really like to have a mixture of technologies i.e. a .Net backend and website with an iOs app that talks to the backend.  We’ll see.

PayDay: Time Frequencies

July 29th, 2010 Comments off

This the first of many posts about the implementation of PayDay, the software that I’m writing to help me with my personal finances.  I’ve been working on the project for a couple of months and one of the first things that I worked on was frequencies for recurring income and expenses.

One of the fundamental concepts in PayDay is the idea of a recurring income or expense.  I need to represent, for example, a monthly income, a weekly train ticket or a fortnightly gym membership.  These bills or income occur every so often, but the every-so-often is different for each one.

Not only that but a recurring item (from now on whenever I say ‘item’ I mean income or expense) has its own start date.  Two monthly items, while they occur as often as each other, might start on different days of the month.  My car loan comes out on the 16th but I’m paid on the 14th, for example.  Also frequencies aren’t always as simple as daily, weekly or monthly because you might want to represent things like ‘every second Tuesday’ or ‘the 14th of the month unless it’s on a weekend then the last Friday before the 14th’.

To implement the functionality of frequencies I considered creating an enum (enumerated type) with all possible types of frequencies.  The problem with this approach is that there are an infinite number of possible frequencies that you can have for a recurring event.  Most things fit into the common frequencies like weekly and monthly, but there are other events whose occurrences have to be specifically determined.  Take, for example, the schedule for being paid monthly.  Most employers will pay on the 14th or 15th of the month except if that date occurs on a weekend or a Monday, in which case the employee will be paid on the Friday so that they have money for that weekend.

Now I can’t think up all possible types of frequencies, yet I want to be able to support new types of frequencies without too much modification.  I could, theoretically, make a frequency engine that you supply parameters and rules to define your frequency but that’s too much work for people who aren’t developers.  Imagine PayDay asking you to “define the parameters of the frequency of this expense” … yeah I wouldn’t use software that asked me to do that!

I need to implement a few common ones and get on with the rest of the application.  I do, though, want to be able to introduce new frequencies later on but also I’d like anyone that writes software that uses the PayDay library to be able to invent their own frequencies without having to touch the PayDay library’s source code.

To accommodate this I created an interface that any class that wants to offer frequency information needs to implement.  I called it ITimeFrequency and it had two methods to implement:


/// Given a date when the event happens,
/// return the date of the next occurrence
DateTime NextOccurence(DateTime occurrence);

/// Given a date when the event happens,
/// return the date of the previous occurrence
DateTime PreviousOccurence(DateTime occurrence);

I really wanted to keep the interface lean. There originally was another method in the interface that returns all the dates of occurrences between a start and end date, but all concrete classes implementing the interface would have the same code for that method I decided to put that method into a static class called TimeFrequency:


public static List<DateTime> OccurrencesInDateRange(
    ITimeFrequency freq,
    DateTime fromDate,
    DateTime toDate
)

So whenever you call TimeFrequency.OccurencesInDateRange(), it’s calling NextOccurence of the ITimeFrequency passed to it to figure out the dates of the occurrencies

I created concrete classes that implement the ITimeFrequency interface: daily, weekly, monthly, yearly and fortnightly.

The general idea with all this is that if you have an event that occurs regularly, you can figure out when that event occurs from when it started onwards. So if I have a weekly event that started on the 26th of July, 2010, I know that the next occurrence will be 2nd of August, 2010 and the next occurrence is the 9th of August and so on. The NextOccurrence() method defined in the ITimeFrequency interface is what calculates what the date of the next occurrence will be. Though the application will not try to calculate occurrences that occur too far into the future, it will calculate all occurrences that occur in the date range that the user is viewing.

After the ITimeFrequency interface and it’s concrete classes was written I hit a snag with the monthly frequency. The issue was that calendar months have different numbers of days, 28, 29, 30 and 31. If something starts on the 31st the next month, unless it’s August, will have less days in it and therefore the next occurrence needs to be the last day of the month; except when the subsequent occurrence is calculated it will not be on the 31st, it will be on either the 30th, 29th or 28th, depending on the month.

Here’s an example: I have a monthly event that starts on the 31st of August. The second occurrence will be the 30th of September. This is because the monthly frequency knows that there is no 31st of September so it chooses the 30th, which is September’s last day. The third occurrence is then calculated but because NextOccurrence() only goes off the date of the previous occurrence, 30th of September in this case, it doesn’t know that the event really should occur on the 31st of October and it erroneously chooses the 30th of October.

What ends up happening is the day the occurrences are meant to happen on eventually go to the 28th. Once the occurrences hit February on a non-leap year that’s it.

So the monthly frequency really needed to have an occurrence day.  The day of the month when an occurrence should happen if the month has that many days. If it doesn’t then the last day of the month is selected. The occurrence day is supplied in the constructor of the monthly frequency object.

Giving the month frequency an occurrence day introduced another issue. If you create a monthly frequency with an occurrence day, then you call it’s NextOccurrence() method with a date that has a day that is different to the monthly frequency’s occurrence day, the method not return a date that is one month after, it will return the next time the occurrence day occurs.

For example: I create a monthly frequency with an occurrence day of the 12th. I then call its NextOccurrence() method with a parameter of the 15th of July, the answer will not be the 15th of August, it will be the 12th of August. Now this is exactly how NextOccurrence() should work. It has given you the correct answer; the next occurrence of the 12th after the 15th of July is the 12th of August, but if I have a recurring item that starts on the 15th yet I’ve declared that it occurs on the 12th, I need a way to tell the user that the dates and frequency they’ve chosen are inconsistent.  To do this the code that calls NextOccurrence() needs to call another method that checks to see if the start date is counted as an occurrence.

/// Is the given date a valid occurrence
bool IsValidOccurence(DateTime occurrence)

Now it’s possible for the recurring item code to check to see if an item’s start date should be counted as an occurrence.

I’ve really tried to make the frequency code open for all kinds of frequencies. The only restriction I have is that the smallest unit of time frequencies can work with is a day. For this application I didn’t want to have sub-day frequencies like hourly and every-minute.

My next post about PayDay I’ll talk about how I’ve dealt with representing money.

My budgeting spreadsheets

July 15th, 2010 Comments off

In this post I’ll explain how my budgeting spreadsheets work.  The first is the spreadsheet I use every pay day to determine how much I can spend and save that month.  The second is a more long term budgeting tool that lets me see how much I need to pay in bills each year and how those bills affect my disposable income.

Every Pay Day

I’ve included an example of an Excel file in this post that you can download: Example Budget Spreadsheet. Remember that this spreadsheet is set up for someone who is paid monthly.  You’d need to change it if you are paid weekly or fortnightly.  The amount of the bills and the income are made up.

Hopefully it’s not too difficult to understand.  The Recurring Monthly Expenses are expenses and bills that occur every month that are the same every month. Expecting this month are expenses that you know you’ll have to pay this month (or more specifically, this pay cycle) that aren’t recurring, they don’t happen every month.

Planned Savings is how much you’re going to try to save right from the beginning of the pay cycle.  You don’t have to have this but it’s always nice to at least have a base saving each pay cycle.

The spreadsheet takes the total of all items in these two lists and the planned savings item.  This total is the amount you would have to pay in bills in expenses.  This money is for all intents and purposes gone.  The money is still in your bank account at the beginning of the pay cycle but since you will have to pay those bills before your next pay day, the money is pretty much off limits for you to spend.

The next time is the take-home pay.  The line after that is the Monthly Allowance which is the pay minus the total in bills and expected expenses.  This allowance is how much you would be allowed to spend for the whole month, until you are paid again.

The next line is Daily Allowance and obviously this denotes how much you are able to spend each day.  This figure is calculated by dividing the monthly allowance figure by the number of days until the next pay day.  Since I don’t know how to determine the number of days between two dates in Excel (which I’m sure is possible with enough Googling) I’ve included the Days until next pay to make the calculation easy.

The Daily Allowance is the magic number.  Using this number you can assign yourself a recurring allowance that’s evenly distributed.  I like having weekly allowances and I like my allowance to start on Thursdays.  In the example I’ve manually set the weeks with start and end dates based on Thursday being the first day of the week.  Notice how there are 5 week entries with the first and last weeks having less than 7 days in them?  Week 1 is like that because May 14 was a Friday and therefore there would only be 6 days until Thursday.  Week 5 ends on Jun 13, which is the day before pay day and therefore should be the end of the week in terms of this pay cycle.

Again, I’m too lazy to figure out how to make Excel determine how many days there are between two dates so I’ve manually entered the number of days in the Days column.  The amount column is simply the Daily Allowance multiplied by the number of days in the allowance week.

What this spreadsheet allows you to do is determine how much you can spend each week during your pay cycle by entering your monthly bills and how much you are being paid.  As good as this is it still requires a bunch of manual steps: determining the number of days in the month, entering the weeks in the month and the number of days for each ‘week’.  Most of those manual steps can be automated in Excel and I might do that and upload a new example in the future.

Spreading out longer term expenses

What I really would like to do is determine how much I should save each pay day for things like car registration, which is a yearly expense.  It’s a simple thing to do at first.  You take how much the bill costs, let’s say $600 for argument’s sake, and divide it by 12, because I’m paid monthly.  I would have to set aside $50 a month to pay for my car’s registration.

The benefit of doing this is obvious; you don’t have to worry about having enough money for those yearly bills because you’ve already saved up the money to pay for it.

Download the Example Budget Forecast Spreadsheet.  You’ll notice 7 worksheets in this spreadsheet.  The first is the Outlook worksheet which shows you a summary of your pay versus your known expenses throughout the year.  The other worksheets are lists of expenses for different frequencies.  For example the Weekly Expenses tab contains all expenses that you know you have to pay every week.

In each expense worksheet the expenses are added together and averaged to be a single Daily Cost figure.  The Daily Cost in the Weekly Expenses worksheet is how much all the expenses for the week will cost you per day.

On the Outlook worksheet the Daily Cost figures for all the expense worksheets are added together to give you the Daily Expense Figure.  This is how much all your expenses for all frequencies (monthly, yearly, every six months etc) cost you per day.  Sobering isn’t it?  Despite the depressing feel you’ll get from this I believe it’s imperative to find out how much you need just to pay the bills.  Only then can you make an informed decision about whether you can take a loan or buy that TV.

The Daily Allowance shows you how much per day you have left after all your bills are paid.  The theory is that if you only spend that amount per day, you’d have saved enough money for all bills, even the ones that come in only once or twice a year.

Yes, but …

Now this is all well and good if you’ve been following this plan from the day you started earning money and paying bills.  The unfortunate situation is that you haven’t.

Let’s look at a simple example; the $600 car registration.  Let’s say I paid my rego (‘rego is Australian slang for Car Registration Fee) in January and it’s now July.  I’ve decided that I need to start saving for my next rego, which is January next year.  If I had started saving in January I’d only have to save $50 every month (remember I’m paid monthly).  Now it’s July and rego is 6 months away, not 12!  I have to save $100 a month if I want to have the money ready to pay it without using my credit card.

But I used my credit card to pay my last rego and I haven’t finished paying that off!  Now I have to save another $100 per month while paying off the credit card bill for the previous rego?

Yeah … I kinda do, unfortunately.  The fact is that if I want to adopt this save-for-future-bills technique I need to go through a period of transition where I’m putting away a lot of money, paying off a bunch of debt and somehow still affording rent and food. It helps if you have some savings left over after every pay day.  That surplus can go into saving for future bills.  You’re going from paying for things after you’ve gotten them to paying for things before you’ve gotten then.  There’s going to be overlap for a period time.

At some point, if  you stick with it, your finances will normalise and you will always have enough money to pay off  your bills.

What started off as a way to see how much I was spending month to month has become a complicated web of dollar signs and dates!  This is why I’ve chosen this subject matter as the basis of a software based passion project.  I want to make this stuff easy for me (and others I guess :P) to do.

My next post will be about how I’ve handled time frequencies in PayDay.  It’ll be a bit technical but hopefully people with non-programming backgrounds will find it entertaining.

Categories: Money, PayDay, Software Development Tags: