I’ve been reading a lot of economics articles recently and have been thinking about our current debt crisis. From a Keynesian perspective, the government should be heavily investing anywhere it can to offset the lack of private investment. The politically popular austerity movements in Europe and the US argue that the fundamental problem is lack of savings, and that higher deficits will not raise short-term demand, but bring long term ruin to these economies. Macroeconomic policy is way to complex of a topic for me to comment on, but I can say a thing or two about Technical Debt and the investment parallel.

Technical Debt, unlike personal debt, is essentially something your organization owes its future self. Much like government savings bonds purchsed during WWII to finance infrastructure and military buildup, you promise your future self that you’ll do some amount of work in exchange for cutting a corner now. When you look at it not as something the developers are borrowing from someone else, but as something you’re borrowing from yourself, you have to weight it accordingly. There will always be hidden or unexpected costs for having taken the easy way out of some problem, but at least take the time to carefully consider the known problems you’ll likely face. So what happens when you’re faced with insurmountable debt?

The parallel for crushing personal debt is declaring bankruptcy, but is this the right approach? Bankruptcy, in this case, means a rewrite. Maybe not ground up, but it does mean you’ll face a lot of second system problems. Rewrites are so alluring to developers, managers and pretty much everyone. However, they also strand your current product in its current state. If you intend to keep updating the old product, while you build a new replacement, you’ll have to saddle a bunch of your developers, probably some of your best ones, with the enviable task of maintaining a dying code base. One that you’ve decided is so bad that it’s unrecoverable and isn’t worth trying to fix. Truly, these engineers you’ve assigned this task will be grateful for the opportunity to “just keep the lights on” while other teams tackle building the replacement.

The other option is to hunker down and fix bugs. No new features until X bugs have been fixed. No more critical path bugs, no more middle of the night downtime, etc. Usually, management will declare this as the stated goal, and it sounds like such a miserable existence because it is. In the financial parallel, we think of it as the individual paying themselves out of debt month by month. In reality it’s more like a stagnant national economy which isn’t investing in itself. Remember, you owe yourself this time to do things right. Fixing bugs on an individual level isn’t the same as repaying your technical debt. Say you took a shortcut somewhere and built a quick version of a message system to keep two in-house systems in sync. In time, you needed to generalize it, but due to constraints you had to just copy/paste configuration files and code between projects without really abstracting things neatly.

Another aspect of long-term debt is that over time inflation rises can decrease the real burden of debt. If your one-off message bus turned out to be built for a feature users didn’t want in the end, it can die, and your debt is absolved painlessly. You saved the effort, accrued debt and over time, it became trivial that you had accumulated it. Technical debt matters most in high-interest scenarios, e.g. your core products and the libraries that comprise them.

What do you think, have you accumulated meaningful debt? Can you pay down your debt by dropping features that aren’t used or necessary? Or is it time to set aside resources and engineers for reinvestment to offset your debt?

I was working on refactoring and updating some code that was written by another team of developers today and eventually found myself in the whack-a-mole cycle of “Commit-Ship to QA-Find Bugs-Commit” for a few iterations. The project had unit tests, but they somehow didn’t cover the cases that were coming up after a few shared methods signatures had changed. I realized that through the (correct at the time) use of mock objects to get tests working at all, the tests had managed to diverge from its actual runtime behavior. It’s not just the responsibility of the initial developers to write unit tests to verify their work, it should be the responsibility of everyone who works on a project. You’ll never get perfect coverage, but if you keep it up to date, and enforce that tests must pass for the project to ship, you might have a chance at keep your code maintainable!

Back in June I attended O’Reilly Velocity in San Jose and on the first night amidst all the great Ignite talks, there was one titled “How to find a place to live in San Francisco“.  As with most Ignite talks, it was fast paced, witty and actually offered some meaningful (if slightly sarcastic) advice on the topic. His summary: bring every piece of info about yourself and a deposit check and just pray you get the place, not exactly uplifting, but I figured this was hyperbole for the sake of entertainment on the presenter’s part. By that point both my employer and I knew I was moving out here and my girlfriend and I had started the daily ritual of combing through apartment listings on craigslist to imagine our lives out here.

Fast forward to July, my girlfriend and I have been constantly trolling craigslist and we’re finally ready to pack it up and make the move happen.  We have temporary residence with relatives outside San Francisco proper, but that’s temporary.  So we start putting open houses on the calendar, and we’re both excited at the prospect of finding our dream apartment in our dream city. Oh to be young(er) and naive(also -er)!

Turns out, there’s a LOT of other people also trying to get apartments around here!  We were early for a few different showings and each time, the place was rented within 15minutes.  We started to become a big dejected.  Looking at apartments we didn’t like was becoming a necessity because at least the possibility of a home was there, even if it wasn’t perfect.  I think the lowest moment was after we’d been looking for about 10 days, been to a couple of showings in one day and all of them were in big, uncharming buildings with crappy hallways and they had all been cattle calls.  50+ people showed for a 15min look at an apartment in the Valencia corridor in the Mission.  All had checkbooks and pre-filled applications.  The place was probably rented before we event made it up to the apartment to look.

A few days later we see an *amazing* apartment come up on craigslist.  We email minutes after its posted (as did almost 100 other people we later found out).  But we were the first, and the man leasing the flat turned out to be rather principled and fair!  So we saw the apartment (bringing of course, all our credit history, pay stubs, bank info, mortgage statements, DNA profile, family criminal history, proof of residency, proof of whateveryouwantjustgiveusthisapartmentplease). It was worth it, we were prepared and on the cusp of full-throttle desperation we convinced the owner to allow us, our two cats and our rabbit to all move in starting in September!

So a few weeks and a lot of awful apartments and one glimmer of hope at the end of it all can lead you to your dream apartment in San Francisco, but patience and hard work are probably the only real tips other than be prepared I can offer.  Good luck, it’s a jungle out there.