At last, a version for the BlackBerry has been released and ready for general public consumption. Make some good decisions this year- based on numbers and data- not just emotional “got-to-have-x” or even more dangerous hype-based “woohoo-the-recession-is-over-we-can-spend-now” motivations. take the time to think it over a little… or use zaFin.

ZaFin is the finally born with the first feature arrived: PAYE. (Hey. It’s a start and a natural one at that given it’s history). Now, ZaFin is a long-term project and has been a goal to get going for a long time now. Essentially, it’s the place to post tools which help you reach numbers you need to make informed decisions for yourselves. Given the state of the world economics at the moment, give me one good reason why would I want to get financial advice from “the system”? It’s track record speaks for itself. Neh. Have the courage to think for yourself, right?

So ZaFin is supposed to be that kind of place. A spot where you can, armed with a bunch of quick little nifty calculators, reach and juggle numbers to come up with a reasonable conclusion. You don’t need an advisor for that. I believe, armed with the right information (ie. numbers) most reasonable folk can come make up their own minds. And make pretty good decisions on their own too (and maybe also check in with an honest friend to bounce some ideas off).

There will be more to come, slowly, over time, as time allows; baby steps. Hope you find the first tool useful, and more importantly, simple to use and to the point giving all you need, and only what you need.

The playground has got a new update: stats-related. We covered the sections where you can uncover a bunch of numerical descriptions on a dataset, which is useful for a quick overall summary of the data. I’ve used this tool a couple of times myself preparing for exams and checking manual calculations (yes, sometimes i need to do this type of thing manually) and of course, it’s much easier than using my Sharp or Casio calculator.
And then there are times when you need to examine the relationship between two variables…

The “Applied” Stats Calculator helps with that quite a bit by giving you a fairly (or so i’d like to think) easy way of inputting your data and then calculating and displaying the relationship through a least-squares attempt on the data provided. There are two motivations for this development:
a) linear relationships are more meaningful than just describing a dataset on its own
b) a showcase in extending the javascript library, complete, as always, with tests.

While explaining Morty, I left with a parting shot: Be careful about consolidating your debt. And before I continue, i will make the disclaimer that I’m not a financial advisor, just a curious number cruncher. So not entirely satisfied about not giving an example, I’ve now had the time to consider the model more carefully to present you with some numbers. So here goes…

Scenario: 2 loans exist, one for a house taken out in May 2004 for 800K at 14%, and one for a car in May 2006 for 160K at 16%. Come May 2009, you decide to consolidate your debt (for whatever reason).  Note, I will purposefully line up the dates and use nice round numbers to get the point across. Also, the interest rates used reasonably reflect the situation in South Africa at the time (as my memory serves).  But regardless of the actual numbers, the same maths (and hence lessons) apply. The math follows:

Home Loan:

• 800K at 14% over 20 years = 9.9K repayment
• You will end up paying 2.4M for the house over 20 years
• That’s 1.6M in interest alone
• After 5 years, you have paid off 600K, but have only 54K in equity

Car Loan:

• 160K at 16% over 5 years = 3.8K repayment
• You will end up paying 230K for the car over 5 years
• That’s 73K in interest alone
• After 3 years, you have paid off 140K, but only have 83K in equity

Now you want to consolidate your outstanding debt under one loan. And, we’ll assume you’re refinancing under more favourable interest rates- else why would you even reconsider it? So what you actually owe at this stage will be the sum of the settlement values on each loan, which will largely depend on the agreements you have in place. Let’s assume everyone plays nice and they let you off with the original loan less your current equity. It could be a lot worse! You now owe a total of approx 840K which you need to refinance, and because one of them is a house, you might end up reasonably re-mortgaging over 20 years again:

New Loan:

• 840K at 11% over 20 years = 9.2K repayment
• You will end up paying 2.2M for the combined loan over 20 years
• That’s 1.4M in interest alone

So, where do you stand at this point?

You’ve definitely made a short-term saving in terms of your monthly repayments (10+4 vs 9). Your cash flow is a lot smoother! But with 2 seperate loans though, you would have paid a grand total of 2.6M (2.4M + 230k) over the lifetime of those loans. With a consolidated loan, you would have paid a grand total of 2.9M (2.2M for new loan plus payments already made on previous loans of 740K). Plus, your cash flow potentially deteriorates over the medium term. Once the car loan would have matured, you’re paying almost the same repayment (especially if by this time the interest rates have dropped) anyway. And then in the long term, you’ve got an extra 5 years of repayments to cover which is worth 0.5M of cash flow in the future.

All, in all, the simple summary of it that is you end up losing approximately 300K in the long run.

But it’s not all that bad- it can actually be to your advantage too. If the difference between the original financing rates and the new financing rates are large enough, you can actually save yourself a lot of money in the short, medium and long term too. But that requires approximately a 5% difference _at least_.

So think twice before you jump fall for the debt consolidation marketing trap. Make sure whoever is advising and structuring it for you that they go through all the numbers and look at it long-term. Obviously the refinancing will always benefit the lender which is expected and acknowledged, but just how much is fair and reasonable? We all have the right to make informed choices- and we should insist on that right- and just because it might sound technical or complicated or involve a lot of numbers, doesn’t mean it can’t be explained in a way that makes sense to you.

Hope that helps to at least think a little more deeply about the choices out there….

Morty is a pet project i been working on here and there which spills out an amortization schedule for you, based on your loan attributes. I’ve been incubating it at Heroku since it is quite a fascinating concept and tool. Their online console is pretty geeky but easy to use and deploying rails apps is straightforward really. Anyhow…. Morty.

Say you considering a loan for (in any currency) $150000 at an annual interest rate of 12%, compounded monthly over 5 years (or 60 compounding periods). Immediately you get an idea of how much your repayments are going to be.

In this case, 3336.67 per month. The schedule part is the interesting bit; if you are indeed interested. First, you can see, at a glance, how your equity in the loan grows and how quickly (slowly) the loan capital is repaid over time.

As you can see, it’s only just after halfway that you start to owe less than you’ve repaid. You will notice slight curves due to the nature of amortization. Experiment with bigger loans and interest rates to see just how the curve is affected.

You can also see how much total interest you end up paying, versus how much of the interest you’ve paid off so far.

Here, the curves are slightly more pronounced. Of the ±50k interest you’re going to pay back in total, most of it is paid off quite early. Which makes sense. The more you owe in the beginning, the more interest you pay. So if you really want to make a difference on the interest on your loan, over time, make the biggest impact you can as early on as possible. You can see that towards the end of the loan, how flat the curve is. If you start making advanced payments at this stage, you’ll still save, but not nearly as much as you could have if you were even one or two months earlier with that payment…

The schedule…

Numbers number numbers. All it is is numbers. The numbers tell you that when you make your first payment of R3336.67, almost half of that payment is paying back the interest. R1500, in this case. So, in effect, you’ve only paid back R1836.67 of the capital (R150k) back after actually paying R3336.67. That starting to make sense now? Sucks, eh? So you make another payment, through enforced religiosity (ie. debit order). This time, you’re _only_ paying back R1481 interest. The balance pays off the capital. And so it goes until eventually you reach a stage where you’re paying off more capital than interest with each payment.

Now take a look at your home loan. An average value in current property markets might be something like R800k at 14% over 20 years (or 240 compounding periods). You’re paying back almost R10k every month but your first 42 payments don’t even dent the capital by more than R1000 at a time. Effectively, after 3.5 years, you’ve paid over R420k back, but still have R767k out of the original R800k owing.

Eish. That’s why credit is so expensive and not everybody can afford to jump into the property game.

Which also brings me to another point… a parting shot, if you like. Think _very_ carefully about the impact of renegotiating your outstanding debt. Imagine: 3.5 years later, and almost half a million out of pocket, you get a generous offer an opportunity to renegotiate your existing debt. In essence, you start all over again. Remember the curve! Another 3.5 years later, another R400k out of pocket, and you’ve only managed to claw back R35k, give or take. Sound like a smart move?

**NOTE: Different institutions structure fees into their loans, so the actual repayments may vary if you ask them for quotes and compare to this calculator. Query the fees. Always.

UPDATE: 3 July 2008
Updated code to reflect more recent tax tables (2009)

When I was asked to estimate PAYE on a gross monthly salary, i hauled out the calculator and started chipping away, according to the SARS Tax Tables. Not being a tax consultant or looking at various structured packages, the first stab is mostly always a straightforward estimate without investigating further deductions. While doing this, the math-programmer inside me went… “Mmmm. Calculator. Boring. Ruby. Smile”

Turns out, it’s a simple little script; a useful little snippet and, bonus, i migrated some more learning onto Ruby. An aside; there’s definitely something about the difference in speed and endurance of learning between my brain versus my hands. You know the feeling. You can forget a password mentally, but let your fingers do the talking… And utilising muscle memory as an aid is just one of the many senses you can draw on…

Back to the snippet. Not too much interesting going on in terms of code. I chose a multidimensional array for storing the tax table. First used a hash, found it was overkill, reverted. Also did a classic switch in the beginning, to determine which “bracket” your pay falls into, but then figured a straightforward loop works just as well. This was an interesting break in habits from C# however.

In C#, looping through an array would be: for(int ii=0;ii<array.length-1;ii++)
I did the same in Ruby, transliterated the code, first time round: for ii in 0..array.length-1
But then, the knowledge of the “times” method changed my thinking completely: 6.times { |ii| … }
There are, afterall, one of 6 tax brackets you are likely to fall in (for all positive salaries)

And that’s where it hit me: the uncomfortable (more about that later) shift away from a corporate-sponsored, statically typed, IDE-integrated, certificate-oriented, compilable(?) programming language into a community-driven, dynamic scripting language is underpinned by these sudden ferocious rushes of freedom. Too much freedom? Certainly, too much to what i’m accustomed to sometimes.

Why’s that uncomfortable? Well, MSDN, VS, MS communities and the framework tell you how to code- to a large extent. They dictate the patterns, the constructs, the idioms; in short, they impose a very definite way of doing things. And it’s a big abstraction layer, forever changing (but not really) and giving you tons of resources to make your coding easier. This is good. Books, online help, built-in help, IDEs, intellisense… and more of all the good stuff. Don’t get me wrong, these things made me very productive and i’m grateful for that. But then you break away from that.

You gotta search for help (no nicely packaged MSDN DVD delivered to your door). You gotta scratch under the hood. You have to engage with community blogs and real people in a virtual world. You are forced to read opinions. You are stripped to the only the most simple of tools- a plain text editor. On a coding level, you are forced to remember namespaces, method names, variable names, libraries… no more intellisense to rely on. And this is where it was difficult. No more crutches to help me be more productive. I had to start thinking- for real now- and remembering stuff. And then i got scared: what if the “community” changed something and i didn’t know about it- or worse, didn’t agree with it? And I didn’t get an email with an updated change delivered to me automatically via updates or DVD? Hang on! Is that really the way it’s supposed to be? Have i become that lazy? Oops.

And all i was doing was having some fun, writing a little script to calculate PAYE so that next time someone asks me, i save myself a little more time.

Btw, the Source Code is here, if you’re interested.

That’s roughly equivalent to the sound of the resonating chord which struck me this morning.

But today’s revolutionaries are sheep in wolves’ clothing. They’re lost in the economically meaningless, in the utterly trivial, in the strategically banal: mostly, they’re cutting deals with one another to…try and sell more ads. That is, when they’re not too busy partying.

Oh, if it weren’t so true. The rest of the article, is soul-searching and uncomfortably challenging because it has that “truth bites” edge to it. It’s also filled with quotable quotes, not for the purpose of quoting, but for serving as reminders when you get enough chance to breathe and realize exactly what it is you are doing.

That is to say, it serves, at the bare minimum, as a reality control against going too far in one direction; but only if it failed to catalyze something deeper within you.

We have a concept of what the learning curve represents, and unfortunately, the same thing can represent 2 opposite concepts. What makes more sense to me is looking at a learning curve from a classical labour cost perspective and more keenly towards labour productivity. In this sense, the learning curve is interpreted, broadly, as: the more you work with something, the more productive (cheaper, better, faster, more knowledgeable) you become. And one can recognise that sentiment when it’s expressed variously with respect to success, specialization, expertise, productivity, quality or minimizing costs. So where’s the investment?

Programming technology changes rapidly, and sometimes to the detriment of programming and business, sometimes not, but also to the advantage of progress and for the sake of technology itself. But changes are also forced to be incremental in order to be successfully adopted, since any radical departure will result in a prohibitively expensive learning curve where the economic costs outweigh the advantages of the change. Similarly, you also cannot force change too frequently, even if it’s small enough, since you never get to break even or realise a profit from the previous change. I think this last point might also be reflected in the current developer attitudes towards the “next big Microsoft thing” and the ubiquitous jading of old hats. Everyone seems to hanging five for a bit before moving forward. Or maybe Douglas Adam’s theory is kicking in?

At the same time though, you need to keep moving forward. So where do you invest your next generation of development so as to minimize the costs of the learning curve if you want to remain marketable and competitive across:
* web development
* mobile application development
* backend systems
* any platform (platform agnostic)

C++, C, C#, VB, Perl, PHP, Python, Ruby… ?

All these languages have their pro’s and con’s and more importantly, costs. As an example, I recently looked at Symbian C++ development, and the learning curve is relatively expensive. The idioms alone take time to get to grips with, so although you got a very powerful API, C++ on Windows desktop, or legacy ATL knowledge is not easily transferrable to a Symbian C++ development effort. Possible, but no as easy as say, being able to use a standard framework and language, with the same idioms, on both (all) platforms. That would be the ultimate prize (for me).

And it doesn’t have to be the same language. Case in point, i’m currently using Monorail (.NET web development) and RoR (other web development) concurrently on different projects and i’m enjoying the benefit of being able to work in a predictable (hence productive) manner switching between the two, relatively seamlessly. Whereas, switching between asp.net webform development and RoR, as an example would not be feasible. The traditional 30% context switch overhead would double.

So if you’re faced with “what to learn next”, take a closer look at the learning curve and where you can (need to) apply that knowledge in the future, in order to remain competitive- whether globally, or within your own department. Maybe it’s stating the obvious, but it’s surprising just how un-obvious the obvious can become when there are a lot of flashing lights going off all the time. So it’s not always about the language or the technology, but also a lot about the “way” in which things are done; which, by nature, is usually a little more sublime to spot since it’s hiding in plain sight

Who’s gonna win?

Judging from the insights that are developing, not only within myself, but also from more prominent journalism, i would say business will eventually catch onto how IT’s supposed to be managed and augmented into adding value to the core focus of the business. Obviously, IT-centric business will be oh so slightly different. But the point is, if you’re a developer (as an example), you should be thinking of how to join the company, not the development team. Your approach and your skill-set should be centered on supporting the core business and not just how good you are at coding. This is a marked difference, and while some have been getting it right, it won’t take long before everyone is forced to get it right. Again, IT-centric (or technologically oriented) organisations will have their subtle differences.

What does that mean in the short term? Don’t think of business as ‘them’. It’s ‘us’. And there’s also no ‘us’ when it comes to the dev team. The ‘us’ is the company.

How do you identify with the change? Well, think of the any other division within your organisation. Accounts, procurement, call-center; any of them, all of them, see themselves as the business or aiding the business directly. They don’t have this distinction (by and large) of ‘there’s us’ and then ‘there’s the business’. It’s the same thing.

Getting this mindshift entrenched as part and parcel of IT as being within the company and not external to the company will certainly be a much needed move forward. The technological advances (again, programming wise) are not that radical; the improvements do need to come from another aspect, and this change looks to be it.

I say “industry” but there’s no real regulation put in by the government (at least here) which keeps the industry in check. For one, it’s not illegal to provide IT services or build software without a licence, while in more established industries, it is illegal to, for example, provide medical, financial, engineering or manufacturing services (where people’s lives are at risk) without a licence. Anyway, that’s not a formal classification or rule, just an idea that appeals to me. Why the necessity to make the distinction?

Over the last decade of building software, i’ve seen a fair share of hair-brained ideas. I’ve also seen some brilliant ones. What i haven’t seen much of though, is brilliant management. I’ve seen some, but these generally come from the business-oriented bunch who just happen to end up in IT; very rarely from tech-savvy management trying to keep a business going. In fact, most of the time, tech-savvy management who try to run their business without business-focused partners end up either working way too much overtime (work = life =work) or going belly up. Somehow, there exists this hype perpetuated by punctuated newsworthy stories of geeks-in-a-garage-cashing-in. So if they can do it, why can’t we? ‘Cos not every story turns out that way.

And particularly software. Manufacturing, distribution or sales, whether it’s IT or food, is the same thing, mostly. That is, the science and art of management has been established and the discipline is well understood. Software, on the other hand, doesn’t fit the mould. Yes, it’s plain manufacturing, distributing and selling, but therein lies the rub. You approach it with business fundamentals, and it works, but if you don’t adapt some of those implementations; you get left behind- and quickly. You toss out the fundamentals in order to keep up; you get dropped behind- even quicker.

As an example, my last company just liquidated. There are lots of different stories as to why, how, when, where or who. Bottom line, no more business. I can only comment on the software aspect; not the rest of the operation. So the only thing i do know is that it was very tricky getting the software strategy just right. Everyone pushed and pulled and chewed on this one all the time trying to get it to work. Maybe, with a little more time, it could have worked out ok in the end? Next time

More evidence supporting the notion that “software is hard”. And it makes me wonder how different things would be if you had to be officially licenced/qualified, by law, to operate in providing a software writing service. Not a fly-by-night programming course. Not a dummy’s guide to programming. Something professionally trustworthy and legally accountable. I wonder just how far would that go towards stabilising the “industry”? Make it more reputable and have governing bodies presiding over fair exchange between vendors and clients; also ultimately curbing the number of software businesses that just don’t make it.

Neh. Where would we be without the hype? It’s part of the magic of this little world