Experilous

A couple months ago I had a crazy idea:  Dump my Excel spreadsheets and just stick all my financial data in script form.  Languages like Lua or JavaScript (through JSON) are naturally designed for representing data, but then they’re complete programming languages too, which readily allows me to implement any amount of custom reporting I want.  So upon starting my game development business, I began tracking my finances using some evolving Lua scripts.  Now that my move to a new place is complete and I’ve finally recorded all the frightening purchases I made over the last two weeks, I’ve been updating the scripts, and chose to port them to JavaScript to gain some advantages from HTML/browser integration and existing high quality JavaScript libraries.  Let me describe the budget scripting experience so far.

I began by separating out the script files into four main pieces.  The first was the utility scripts which would support any generic budget, mostly just defining object types and utility functions.  The second was the structure of my particular budget, defined predominantly by which funds I had (bank accounts, investment accounts, cash, et cetera).  The third piece was a record of all activities, such as purchases, income, stock trading, and so forth.  Finally, my fourth script contained report algorithms that would execute on the supplied data.

The idea would be that the record of activities would be the only file frequently modified, and thus would be in whatever format would be most natural for editing.  Each time I bought something, I could append a structured expense object to the list of expenditures, specifying various details such as the price, the fund(s) I withdrew from to pay for the expense, any fees associated with the expense (such as sales tax or tip), itemized data if desired, and a flexible set of tags to categorize the expense.  For stocks, I could record each buy, sell, and dividend activity, as well as just record the daily closing prices of all stocks that I owned.

From there, the reporting scripts could simply iterate over all the data and perform any desired action.  If I wanted to transform the data from the easy-to-edit style into an easy-to-compute style, I could run it through one pass to do so, and then take multiple passes on the new data to extract any trends or generate whatever other reports I could dream up.

Further, if I ever got sufficiently ambitious, it would be easy enough to wrap any portion of the process with a nicer user interface.  (So far I’ve only been running the scripts from the command line and getting purely textual output.)

I liked the flexibility very much.  If I wanted to store detailed and complex data, it wasn’t hard.  Tags on each purchase and even each item allowed me to categorize things in meaningful ways.  Even though I didn’t yet do any reporting on based on tags, I knew that I could always go back and add them later, knowing that the data already had some useful tags.  Breaking purchases down however I wished, such as recording arbitrary fees and discounts, or listing individual items, multiple withdrawals or deposits (such as when I got cash back at the store from my debit card), was also easy.  These tasks would have been notoriously difficult using a spreadsheet.  Even using a relational database would have been a pain, having to set up all the tables ahead of time.  But using a dynamically typed scripting language made it a breeze.

Here’s an example of what my scripts looked like (with totally made up numbers; don’t try to infer anything from them):

With something like that I could get summarized data such as:

I was also able to carry over some of my investment analysis formulas from my spreadsheets that helped me decide appropriate prices for buying and selling stocks, given my various strategies that are probably awful because I barely know what I’m doing and have been learning stock trading on my own.

Summary

It’s taken time getting this system organized, but so far I’ve been liking it, and consider it worth the effort.  It can be structured enough to make common data entry easy, but flexible enough to allow unusual data without frustration.  And if some of the unusual data turns out to be usual, it’s always simple enough to add in some wrapper objects and helper functions to make the frequent but messy stuff easy to enter.

I also feel comfortable throwing in as much or as little detail per entry that I want.  If it isn’t immediately used by any report, it sits there out of the way, but it is available should I ever want to poke at it.  And I have less worry about getting the design wrong the first time.  Code generates more code all the time with scripting languages, right?  If I ever want to rework some of the structure or helper functions, I can always just write a report script that, instead of printing out summarized numbers, spits out a new script file of the same data but in the updated format.

So for any other programmers out there, I’d definitely recommend considering this approach, as it can be highly adapted to each individual’s own perspective on budget management.  Plus, it’s kinda just a fun non-overwhelming side project.

As I stated at the beginning, I’m in the process of converting this system to JavaScript, and adjusting the structure based on some of what I’ve learned.  I also aim to take advantage of HTML/browser integration, displaying my data in a prettier format, and leveraging graphing libraries such as jqplot.  Eventually I might even support proper input methods through HTML so that I only need to touch the script files directly when I have unusual data or am updating the system.  I’ll report back once I have at least some of those features implemented and behaving properly.

No Comments

Leave a comment