Tag Archives: software

A new breath of life for my A3 HD-DVD player

I appreciate that even though Toshiba threw in the towel on the HD-DVD front over a year ago, their software team is still working on fixing issues with equipment out there.  My wife got me an A3 before the war was lost, which doesn’t really get much of a work out as a HD player, but is one of the best DVD upscales I’ve ever seen (Babylon 5 is the best upscale test I’ve seen, the interlacing on that dvd gives many upscalers aweful fits, but on the A3 it looks pretty respectable).

The problem is that it started crashing a lot on startup.  It had gotten to the point where 1 in 2 startups didn’t work (1 in 3 shutdowns crashed as well).  This might have been related to the lightning that took out the ethernet card, it’s hard to tell.  Regardless, it got to the point where I was about to replace it with just an upscaling dvd player.

However, I found that toshiba pushed out a version 4 firmware last fall.  I did the upgrade yesterday, which appeared to fix a whole host of problems, including cutting at least 30% (if not 50%) off the boot time (which is now at 15 seconds to get to the logo, still long, but on par with all the HD devices).  6 power cycles later, and I haven’t seen a crash *yet*.  We’ll see if that holds up.  If so, the A3 gets to stay for a while longer.

Thinking about Debt

I’ve been thinking about a lot of things in terms of debt recently, and the world looks a bit different if you do that. Debt is borrowing against the future, be that in time, money, energy, health, etc. Debt is what you get when you take short cuts, as you are borrowing from the future.

When your debt is money, it’s somewhat easy to understand. You take money from the future you which you have to pay back at some point. It’s a little harder to understand in areas that aren’t money.

If you create a new piece of code you are creating both value and debt. Debt is created by taking shortcuts, as the software will need to be reworked to reasonably extend it in the future. You take a short cut now to pay for it later, with interest. Every future feature will take longer until you pay back your debt. Refactoring is really all about paying down debt in a responsible way in software.

Most of the time the right approach is to pay off your debt. The other option is bankruptcy (which we are seeing a lot of this week in the financial world). Software bankruptcy is throwing the whole thing out and starting from scratch.

When I started thinking about software development in terms of debt in the last few weeks, lots of things started to make a lot more sense. Shortcuts are debt. Inconsistent interfaces are debt. Inconsistent coding style is debt. Bad or wrong abstractions are debt. Missing documentation is debt. Confusing APIs are debt. If you want a project to move forward more productively you need to eliminate some of your debt, as it’s what slows people down (green field code is easy, brownfield is hard).

I’d love to hear about other concepts of debt, and what debt looks like in other media besides software. Please post comments if you are so inclined.

Software is Lettuce, not Gold

I’ve been listening to The World is Flat on audio book, as part of my summer run through of popular non fiction of the last couple of years. One phrase really struck me on the way home, which was the assessment by Brian Behlendorf that

“software is lettuce, not gold”

Software is both a commodity and perishable if not consumed in a timely manner. For the doubters out there, check out the ranks of abandoned software on sourceforge.net some time. My proud collection of shirts from software companies that don’t exist any more is a less compelling, though more close to home, reminder of that fact.