January 2011 – Andrew E. Scott

Three is not the magic number

About a week ago, Demographia published their 7th Annual International Housing Affordability Survey. They picked up some press for finding that Sydney was the least affordable major housing market outside of Hong Kong, and Melbourne wasn’t that much better. Both were labelled “severely unaffordable”.

And while there is some irony in using the term “unaffordable” to describe the prices at which actual sales occurred (in any case, I agree that Australian capital city houses are expensive), it is the methodology of the survey that I want to nit-pick. It is based on a ratio that Demographia call the “Median Multiple”, which is calculated by dividing the median house (i.e. not apartment) sale price in that market for that period by the median household income for that market at that point in time. Apparently, such a measure is endorsed by such august bodies as the UN, the World Bank and Harvard.

I have previously talked about the mistakes that can be made in comparing two different medians, and it should be clear that there is no reason to assume any particular relationship between (say) today’s median Melbourne household income and the median sale price of a house in Melbourne over the last quarter. Ideally, the median should be calculated on the set of individual house affordability ratios, rather than a ratio calculated from the medians of two somewhat independent sets.

But the major issue I have with the report is that it picks, seemingly out of the air, the value “3.0” as value that separates unaffordable markets from affordable markets, as if it is some kind of universal constant. In fact, the value seems to be chosen principally because, in the past, affordability ratios were less than 3.0:

As Anthony Richards of the Reserve Bank of Australia has shown, the price to income ratio was at or below 3.0 in Australia, Canada, Ireland, New Zealand, the United Kingdom and the United States until the late 1980s or late 1990s, depending on the nation.

In fact, it should be clear that in a country like Australia, and specifically in cities like Melbourne, you would expect their Median Multiple figure to generally increase over time. Hence, there is no constant value that can be used for this ratio to indicate whether the housing market is out of whack.

For the Median Multiple to increase, basically median property values need to grow faster than median income. From my point of view, there are two obvious drivers for this growth to occur.

1. Gentrification

The Australian Housing and Urban Research Institute (AHURI) recently published a report on the gentrification of Melbourne and Sydney. (Essentially, this is when the existing residents of an area are displaced by a wealthier demographic.) For Melbourne, the regions of Maribyrnong and Northcote were identified as undergoing gentrification.

In such cases, property prices rise because people with higher incomes move into the neighbourhood. Actual incomes don’t necessarily rise at all – it’s just people moving around.

When an area has little ability to accommodate the displaced, e.g. through supporting greater housing density from subdividing lots or building apartment blocks, they need to find somewhere else to live. According to AHURI, displaced residents commonly relocate to an adjoining suburb (e.g. in 44% of cases of employed renters or 38% of owners). As they note, this in turn creates a “rippling effect” of gentrifying another region, and then another.

2. Trading Up

A major constraint to purchasing property is the ability to borrow money. First Home Buyers feel this pain worst of all, because (unless a significant deposit has been saved) they typically borrow between 80-90% of the purchase price.

However, everyone else in the market (by definition) has already purchased a home. So, when trading up, any additional amount to be borrowed will depend on the difference between the value of the current property and the value of the next.

Since banks limit the amount they lend based on a household’s income levels, clearly if a purchase relies principally on borrowing, it will be constrained by income level. But, if a purchase makes use of the equity in an existing home, it can go beyond income level.

Admittedly, this requires property values to grow, in order for the home owner to build up equity. So, it’s somewhat circular to argue that growth in property depends on growing property values. However, the growth in equity is typically much faster than the growth in the underlying property value, which is why subsequent properties can be purchased at a level equivalent to growth faster than income.

For example, a property purchased on a 10% deposit will, after five years, have had its equity grow the equivalent of about 30% per year, if the underlying property value grows just 5% per year for that period (assuming the mortgage isn’t paid down at all). Or more specifically, a $400k property on a $360k mortgage will end up as a $510k property with $150k of equity under those conditions. If the household income has also grown during that period, then the mortgage that could be serviced at the same level (as the mortgage at time of purchase) will have grown at the same rate. Putting that together with the increased equity is how the purchase price of the next home grows faster than income, while keeping the portion of income used to service the loans at about the same.

Australia has a large proportion of home owners as possessors of property. The recent AHURI policy bulletin on Australia’s changing patterns of home ownership noted that the home ownership level continued to remain around 70% of the population. Together with tax treatment that allows home owners to sell their property without any tax implications (versus, say, investors who would be up for GST), this creates an environment where trading up is encouraged.

Concluding remarks

So, if you’ve read this far, you’ll hopefully now agree that the Median Multiple price-to-income ratio is likely to increase over time in Australia, and hence there is no constant level of affordability that relates to it. 3.0 is not the magic number of affordability.

To conclude, I will leave you with a graph from an RBA speech on housing costs showing how, as you’d expect, the price-to-income ratio for Australian property has fluctuated, but trended up over the last 15 years (blue line).

Another tweak to the blog

WordPress can be frustrating. It’s the software that I run my blog on, and while the fact that it’s open source gives me the option to tweak it, I would rather that I didn’t constantly need to tweak it.

They have an impressive release cycle: in the last two years there have been three major releases and twelve minor releases. Any of those releases has the potential to break things, or at least render things obsolete.

While having a WordPress plugin of my own means that I have knowingly signed up to this sort of pain, it also applies to my ordinary usage of WordPress which I host myself, as any of the plugins I use may break upon an “upgrade” or my theme may need some editing to keep it in sync with the now-available features.

I picked up my current theme in 2006 – I think it actually dates from 2005 – and it predates a number of WordPress features that are useful to me. Over time, I have added into it: widget support, compatibility with the new image editor, avatars, favicon, and OpenID.

Ever since I criticised Facebook for not being able to reply to specify comments (also known as “threaded comments”), I’ve meant to enable this WordPress feature on my blog. This weekend, I finally got around to implementing it, thanks to others who have previously documented clearly how to do it. It was relatively straightforward, but did require changes in a number of places across several files.

So, if you’ve been waiting for an excuse to write a comment on the blog, then helping test drive this new tweak could just be it!

Division of Labour

It’s something that I think all couples, and in particular, all parents grapple with: how to fairly divide up the housework. I know that some of my friends have also written about it.

One of the best things I’ve ever read about the division of parenting and housework between the sexes was on the New York Times, and if you’re interested in the topic, I recommend you go read it right now. It’s well researched, balanced and insightful.

And in that article, there’s a reference to something that blew my mind. It’s research done by Professor Esther Rothblum at the San Diego State University. Rothblum’s work, published in 2005, compared the amount of hours spent on housework between the sexes, taking into account whether they were gay or straight.

Given that the typical study into sharing of housework finds that men spend much less time doing housework than women, I expected that heterosexual men also on average spend less time doing housework than homosexual women, or even homosexual men. However, that’s not what Rothblum found when she looked at gay and straight couples’ division of labour.

The research concluded that on average 6-10 hrs of housework per week was performed each by lesbians, gay men, and straight men, and 11-20 hrs per week for straight women. (“6-10 hrs” and “11-20 hrs” were different responses in a survey.) A corollary would be that heterosexual couples spend more time in total on housework than gay couples.

Why might this be so? It’s not clear. Rothblum doesn’t go into that aspect in her study, as she seems more interested in the relative share between partners than the absolute numbers.

However, some possible explanations that come to mind are:

There may be some kind of cultural pressure that applies in the female heterosexual community, but not in the homosexual community or the male heterosexual community, that requires women to keep their house to a higher standard. (But can such communities be distinct enough for this effect to have significant force?)
When straight couples have children, it is known to reinforce traditional gender roles, resulting in women spending more time on household duties than they did prior to children. Perhaps gay couples are less likely to have children and this reinforcing effect is then less likely to occur.
Straight men may be, on average, so bad at housework that more time is required by straight women to keep a house to the same standard as that of a gay couple’s, even when straight men spend the same amount of time doing it as, say, gay men. (But if they are “practicing” for the same amount of time each week, why would they be worse?)
Men are likely to overestimate the amount of time spent doing housework on a survey, and surveys were used in this research. But does this apply only to straight men and not to gay men?
About 200 people in each category were surveyed, and perhaps not enough people were included to get a representative result of the whole country. Although, the women’s results were statistically significant (p < 0.0005).

Still, this is a counter-intuitive finding, and it would be interesting to see if other research reinforces the conclusion. If valid, it may go some way toward defending (heterosexual) men against the charge of not pulling their weight around the home.

But in any case, these results describe average situations across a large number of couples. There’s no “right” figure, of course. Every couple needs to find their own balance, taking into account their own unique circumstances. Which is why, I guess, it’s interesting for us all to write about it.

A Java ME coder looks at Android

I’ve had a long association with Java programming.

I started playing around with Java software development back in 1995, before the platform was even released as version 1.0. In 2001, I got my hands on a Siemens SL45i handset and began to develop using Java ME (known as J2ME at the time), a cut-down version of Java for embedded devices such as mobile phones. For a time, I worked for mobile games developer Glu (known as Macrospace at the time) porting games to different Java ME handsets.

That’s all just so I can say that I got to know a lot of the ins and outs of doing Java development for mobiles. Although, I haven’t really done much of that recently, and these days Java ME has fallen out of favour, with the rise of smartphones that support other software platforms. However, Android-based smartphones are now becoming popular, and Android applications are written using Java.

So, I was rather curious as to what developing on Android was like, and over the last couple of months, I’ve spent an hour or two every 2-3 days tinkering around with an Android project as a hobby. This was my chief diversion during the weeks after our daughter was born in November.

I didn’t do an Android course or read an Android book. I simply took what Google provided on Android and ran with it, to see what I would learn.

Getting going

Google makes a lot of really good information and tools for Android available for free. I was able to easily set up a development environment on our laptop (an old Dell Inspiron 1501). Unlike if I’d been developing for, say, the Apple iPhone, I didn’t need to get a specific brand of computer, nor pay anyone to join their development program. In fact, they even make the full source code for Android available if you want to see how it works under the hood.

It made me think how empowering this is for people. In years gone by, if you wanted to tweak your car (or even build a car up from parts), you could easily get access to the information and tools to do it yourself. For modern cars, that’s not really the case. However, it is the case for your modern mobile phone, and given how important a tool it has become in our daily lives, that’s a really liberating thing.

In fact, our particular laptop has a comparable amount of grunt to a modern mobile phone (such as an HTC Desire), so it’s no wonder I find myself doing more tasks on a handset rather than this laptop. In addition, while with Java ME, it was common to test the software on an emulator (e.g. running on the laptop) before loading it onto a real device, but here, the inability of the laptop to emulate a modern handset at anything like real speed made that impractical. Also, the Android adb tool does a great job of exposing logging and debug information in real-time from devices, so there’s no real penalty in testing directly on the device.

Also due to the lack of grunt, rather than using the normal Eclipse development environment, I ended up using the much more lightweight ant and vi tools. Not very pretty, but fast on my machine.

Developing

Android development is theoretically done using the full Java SE, rather than the cut-down Java ME. While it is true that there is a lot more power and flexibility in the hands of developers than there was for Java ME, there are still a lot of wrinkles that make it unlike full Java SE.

Three examples of these wrinkles are:

AndroidManifest.xml: This is a text file that is included in every Android app, and basically describes how the system should interact with the app. Instead of this being specified in the Java code, it needs to be separately documented here. For example, it specifies which icons appear in the list of launchable applications and which classes should be invoked when those icons are selected. It also specifies how other applications on the device might interwork with the app.
Activity-oriented architecture: Every Android app is basically broken into components of four different types. These are the Activity (an interactive screen of some kind), Service (an invisible, background task), ContentProvider (a database-like interface to some content), and a BroadcastReceiver (waits for a system-wide event to perform a task upon). These components communicate with each other using a type of message called an Intent, which is typically a URI and some associated metadata. (My small hobby application used a ContentProvider, a Service, and several Activities.)
Dalvik Virtual Machine: Instead of compiled Java bytecode running on a Java virtual machine (the typical approach for Java SE), the compiled Java bytecode is converted into Dalvik bytecode and that is run on the Dalvik virtual machine. This is a pretty clever way to allow developers to reuse the well-known Java tools but allow the Android system to operate outside of them. However, as the Java to Dalvik conversion doesn’t have full knowledge of the original source code, it seems to find it difficult to optimise things automatically, and leads to strange advice like manually copying class fields into local variables to make execution more efficient.

Another interesting thing, from a mobile developer perspective, is that Android manages a “stack” of screens (Activities) in a similar way that was done for the old WAP/WML 1.1 browsers (and HDML browsers before them). The developer can push screens onto the stack in various ways, while the user hits the back button to pop them off. Given that this approach was dropped from the newer versions of WAP (and in the newer mobile browsers that followed), it is with some nostalgia that I see it come back again. However, it does make a lot of sense for mobile handsets and their small screens (i.e. the impracticality of having several windows open side-by-side).

Difficulties

While the Android SDK gives the developer a lot of power, it wasn’t as easy to use as I’d hoped. Not that Java ME was easy, by any means, but Android’s design and development has probably resulted in some strangeness that Java ME avoided.

You have to remember that Java ME evolved in a (some would say ponderously) slow fashion. It was effectively the product of a standards organisation, with a lot of smart minds spending time arguing about small details. For example, while JSR-37 (the original specification of the version of Java ME for mobile phones) was published in September 1999, it took until August 2002 for the specification for sending a text message to become available (JSR-120). The final result was typically elegant, consistent with overall Java ME design philosophy, and extensively documented. But you didn’t want to hold your breath for it.

I was developing to Android v2.2, which was the 8th release of the platform (not counting revisions). There had been five separate releases of the platform in the previous year (from the 3rd release in April 2009 to the 8th release in May 2010). It has been evolving very quickly, so I wasn’t too shocked to find things worked in unexpected ways.

I found the Android API library to be a bit confusing. Classes weren’t always in the packages that I expected to find them. For example, while Activity and Service are in android.app, ContentProvider and BroadcastReceiver are in android.content. Also, some UI elements are in android.view and others are in android.widget. And while some standard icons were available as constant values, others needed to be copied as files out of the SDK.

The Activity-oriented software architecture also took a while to get used to. It turned out that although one method I tried to use (startActivity) was available on some classes (such as a Service), they would throw an error if called because they were only meant to be called from particular components (an Activity, in this case).

Additionally, while ordinarily an application runs in a single process, it uses a number of threads. There is one special thread called the UI Thread. Again, one method that I tried to use (showDialog) was available in a class, but silently failed when it was called from a thread other than the UI Thread. In practice, you need to use an Android construct called a Handler to pass messages from one thread to another to allow the right thread to invoke the right method.

Also, seemingly harkening back to the days of Java ME, the media library seemed to have frustrating bugs. One API call I was expecting to use as documented (MediaPlayer.setDataSource) turned out not to work at all, and that I had to specify a FileDescriptor rather than a file path to load a media file. Also, another API (MediaPlayer.getCurrentPosition) returned completely erroneous values, and I had to develop a work-around. Thank goodness for StackOverflow in both these cases.

Conclusions

In the end, I got my little app working nicely. It was very satisfying to find that there was the ability to effectively add a new feature into my phone.

In that sense, Android gives user-developers a lot of power. And while I was expecting it to be a straightforward Java SE like development exercise, I discovered that it had a lot more in common with Java ME development. I had hoped that such platforms would easily attract the large pool of desktop developers, but it seems that there is still a mobile-specific learning curve that a developer will need to go through, and this will shrink the available pool of expert developers.

That said, I hope that Java developers will take a look at Android and see what kind of features they can innovate on top of it. As for myself, I hope to find the time for another hobby project again soon.

The second child

I return to work in just a few days, leaving Kate to carry the burden of two small children on her own. Although the time spent with my family over the last six weeks has been great, it can’t go on forever without someone working.

But reflecting on what it has been like this time, compared to the last time we had a newborn, I’ve realised how different these weeks have been.

For our first child, Harriet, we were jumping off a cliff together and we didn’t know what was at the bottom. We lacked confidence, we lacked knowledge, and the only thing we knew was that our lifestyle would be changed irrevocably.

To prepare that time, I read books and went to classes, read my parent friends’ blogs and stocked-up on frozen dinners. And it was all very helpful, and we survived intact.

This time, for our second child, Philippa, I waited until a week before and re-read parts of one book for preparation. A major difference was that this time, we had knowledge (although, a quick refresher helped) and confidence.

But what we had last time that we didn’t have last time was time. While last time, we could relax, rest or sleep during the periods when the newborn was unconscious, this time we didn’t have that luxury.

As well as Harriet having long awake periods, she has also realised that she needs to be more demanding to achieve the level of attention she received pre-Philippa. This may also be explained by simply being two-year-old age, but some is likely due to the competition.

One aspect that is easier is we’ve now well and truly given up on our old lifestyle. Going out most evenings is now a distant memory. The struggle to retain some of the old lifestyle was a part of the adjustment in having Harriet in our lives, and this is a struggle that didn’t need to be repeated for Philippa. I guess this is an advantage in having the two children relatively close together – we hadn’t strayed too far from the way of living that we’d developed to accommodate a baby.

There are plenty of nice things about having another little baby around, though it’s hard not to look back on the early days with Harriet fondly, to now think of how good we had it. This is, of course, looking with eyes that now have the confidence and knowledge that we didn’t have back then, but the yearning for more time is very strong.

So, it’s unsurprising that many of the strategies that we’ve discussed for when I return to work involve getting Kate more time. For example, enrolling Harriet in care for one day a week, visiting Kate’s parents to share the kids around for one day a fortnight, etc.

I know we’re not the first people to have a second child, so it can clearly be made to work. I guess we’ll find out how.