Apple Professional Apps Documentation Goes on the Web

The complete documentation for Apple's professional apps is now available on the web.
Links to the individual products are:

• Apple Loops Utility Help
• Apple Qadministrator Help
• Apple Qmaster Help
• Batch Monitor Help
• Cinema Tools Help
• Color Help
• Compressor Help
• DVD Studio Pro Help
• Final Cut Pro Help
• Final Cut Server Help
• Impulse Response Utility Help
• Logic Pro Help
• MainStage Help
• Motion Help
• Soundtrack Pro Help
• WaveBurner Help

Josh Keppel reviews some Oakland California Burning Man cultural spin-offs

Flamethrower SHooting Gallery crew member Josh Keppel is also a writer for NBC Bay Area - a San Francisco Bay Area local news and events web site. Josh recently wrote a review of some Oakland-based hot-cultire events. Have a look.

Why Technical Debt Should Be More Visible

Recently my colleague Jeffrey Thalhammer of Imaginative Software sent me a pointer to Steve McConnell's article on Technical Debt: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx

Instead of sending Jeff an email with all my notes, I'm sending him a pointer to this posting.

Overall I thought the article plus the comments were very good. The comments and back-and-forth really add  a lot of value the the article and I suggest anyone reading the article make their way all the way through the comments.

I think we should write a version of this aimed entirely at non-technical people.

McConnell does acknowledge that estimating the "interest payments" is very difficult. One of the (maybe not so obvious?) reasons is that involves calculating the expected lifetime of the system, because as the article says:

When a system is retired, all of the system's technical debt is retired with it. Once a system has been taken out of production, there's no difference between a "clean and correct" solution and a "quick and dirty" solution.

So having a realistic estimate of the expected lifetime of the system make a huge difference it the expected cost of the debt.

I also like the attention that the article and comments gave to the issue of why different people may have different attitudes towards technical debt. For example, the article says:

The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred.

and commenter Robin Barooah said:

This might further explain why business people are prepared to accept technical debt - they aren't the ones who are going to have to pay it off.  The developers suffer real consequences because they aren't learning or growing by having to rework code that they knew was being done to substandard quality in the first place.

I think Barooah's comment is spot-on and indicates an often unarticulated and under appreciated difference between financial and technical debt.

The article summarizes some of this by saying that:

The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it.

I would amend that to say "so some people have" cf. Barooah's comment above, but I basically agree: making the "technical debt" more visible is fundamental to improving how it is handled. That means means finding ways to make it visible to people with different perspectives: Finding indicators that are equally meaningful to both business and technical staff would be a big help.

Technorati Tags: agile, estimating, programming, software development