Publish or perish

I'm thinking I should write a paper. Publishing something would score some big points with the UMSL faculty at a time I really, really, want them to transfer a lot of credits from my Master's work. So, I'm looking at potential topics:

• A method for pulling non-rectangular areas out of an OLAP cube. This one is the most obvious candidate because I've already done the work. I just need to write it up. My current employer can't even get mad about it because most of the research was off hours and they never implemented it (though we certainly had it ready to go). Basically, we put a superstructure on top of all the business attributes that allow us to build a hierarchy where the selection criteria at deeper levels is dependent on the selection already made at higher levels. It's actually pretty kick-ass. I have no idea why our users didn't fund the development because it's exactly what they asked for. Anyway, one of the other architects and I got far enough with the design that I could implement a rough version with probably only around 40 hours of work. That would be enough to collect some metrics on performance (to show that it's better than just running a bunch of independent queries and then trying to tie them together with PowerPivot) and write up the results.
• The Ultrarunner's Guide to Long IT Projects. I know this sounds fluffy, but it's really not. I have a ton of experience in both of these areas and the overlap in successful strategies is no coincidence. The two disciplines require the same mindset. Not sure where I'd publish this, but I've given it a fair bit of thought and I think I could write a pretty good paper in 20-30 hours. Or, I could do a really fun interactive presentation. If I can find an appropriate forum, that might be the way to go.
• Test Driven Design for database programming. TDD is all the rage but, if you're going to enforce the criteria that unit tests can't hit the database, you're pretty much S.O.L. trying to apply this to database programming. I've found some ways to relax that rule that don't violate the other tenets of good unit test design or of TDD in general. I could probably write this one up quicker than the other two, but I'd have to spend a good bit of time making sure that I wasn't repeating what someone else has already said. I haven't seen anything in the literature about it, but I could have easily missed it.