10 November 2005

Time and deficit spending

In the software business, time is precious.

Software engineering teams often borrow time from the future at a very steep interest rate. Two examples:

  1. A team is hurrying toward a deadline. The team has painstakingly produced a detailed design document for the product. To save time on the current release, the team stops updating the document as changes are made. The plan is to bring it back up to date after the deadline.

  2. A company has a product for Windows. The company needs to ship the same product for Mac OS X. One plan would be to rework the Windows codebase to make it platform-neutral. Instead, the team chooses an alternate plan. They branch the two codebases. This allows feature development and releases to continue at speed on the Windows branch, while the new branch works on OS X support. Both projects will reach near-term milestones sooner. The long-term plan is to merge the two codebases, a time-consuming task.

In each of these cases, the team gets extra time now, at the expense of time later. In each case, they must either spend the time later to clean up the mess; or lose a lot of work.

I suspect the interest rate on these loans is high (200%-ish), but then the expected ROI for time (as opposed to cash) can be very high as well.

How should these decisions be made?

1 comment:

Mattie said...

I truly wish I knew the answer to that.

When I don't have to do the up-front work myself, then I always recommend the "pay for it now" approach.

The high interest loan can hurt. Yet, in some cases it feels like more of a gamble than a loan. In software, there are times when you get out of repaying the loan. Other times you only have to pay the regular interest payment without ever paying back the principal directly.

I guess it usually ends up one of three ways:
1. You pay back the loan in full.
2. The project is eventually cancelled and the loan disappears in 'default'. This could happen for reasons that have nothing to do with the shortcut (market/other flaws/etc) and might not cause you any harm at all.
3. You accumulate a lot of these loans over time in a long project, pay some interest, and then pay for all the loans at once when you can get multiple birds with one stone. (E.g. many 'shortcut designs' might be salvaged in a single full redesign, new technology, or a product acquisition.)

As such, I think over time the shortcut situations probably cost companies a little less than it looks (especially if you consider the likely short-term return you received).

It's so hard to know what the true cost is. Maybe I'll start a company that shortcuts everything. Once the product hits design-flaw critical mass, we'll throw it away and work on a different product entirely. It'll be my new programming methodology: Screw Tomorrow.