In Defence of Technical Debt

Saturday 28th February, 2009

I love metaphors, and this one is great.

Technical Debt is the idea that as you develop software, any corners that you cut can be thought of as borrowing time, which incurs interest (maintenance cost) and must sooner or later be paid back (by refactoring). So, creating crufty code because it’s quicker often results in having to go back and re-do it.

Fine, but why does the metaphor stop there? Everyone loves beautiful code and elegant algorithms, sure. As a profession we don’t like mess, and we respect clever ideas than can do complex things without that mess. Makes sense.

However, debt has a positive side too. If you have a business idea but don’t have the start-up capital, you borrow it from someone who does. It saves you time, and possibly enables you during a window that might be closed 6 months later. Without that debt you would have missed your chance. If you want to buy a home, you either borrow and live in your own home for most of your life, or save up the long way and are only able to afford your home by the time you retire.

The same concepts exist in software.

If you’re developing software you have a window of opportunity which will not last forever. If you tried to sell a competitor to Windows 3.1 in 2009 you’d be laughed out of the industry. If you tried to start a new Javascript framework now that JQuery, Dojo, and the like are mature you’ll have a very hard time. You have to be able to move quickly.

Similarly if you’ve got a project to get out, without being able to predict the future you’ll have a hard time designing some components, as you don’t always know how their use will change over time. By borrowing a small amount of time early on, you can often save yourself from wasting time trying to cover every eventuality and getting lost in a maze of total abstraction. By the time you actually get to the later stages of the project you’ll often find that you were completely mistaken about the likely outcome… and that time you’d spent refactoring early was wasted.

By borrowing time you often gain. Think of it less like ‘technical debt’ and more like ‘technical leverage’. Don’t waste it by paying it off before you’ve had a chance to benefit.

6 Weeks in, Grails hasn’t disappointed

Wednesday 25th February, 2009

Today I came across a slightly annoying bug in the Groovy compiler that means that static variables declared in interfaces don’t always make the conversion from Groovy to Java intact. Everything after the static variable name is lost.

While bugs like this are always frustrating, I actually consider it a pretty good sign that this is the only real obstacle that this framework has presented so far.

We’re due to release some new code at the beginning of March, including a new version of our visual similarity engine, so expect posts about related topics soon.

To Browse or to Search?

Wednesday 25th February, 2009

One of the major shifts in e-commerce site navigation over the past few years has been the widespread addition of search facets, allowing users to navigate a collection of items using the different properties of the items in the collection.

You can see examples of this on every large e-commerce site from Amazon to Dabs. When you search they break down the results into groups and allow you to refine your search by telling you how many of your search results fall into each classification or category.

While this form of navigation is irreplacable for the initiated, there are still questions as to whether casual arrivals to sites are willing to engage with on-site navigation rather than retreating to the search engine of choice (okay, let’s just get over the little nicities and say Google).

ReadWriteWeb are reporting the latest figures from Hitwise that seem to show users are moving towards more and more complex search refinement using internet search, which I’m guessing means that either people are searching for more specific things, or they’re less frequently choosing a known site and its internal navigation.

Sites that invest time and money in the design of their on-site navigation would do well to pay attention to changes in their traffic patterns, and adapt their use cases accordingly.

Mozilla requires you to log into to install experimental add-ons

Friday 6th February, 2009

From Mozilla: “The add-on site requires that users log in to install experimental add-ons as a reminder that you are about to undertake a risk step.”

…and providing your personal data to a third party is another risk step. Irony is not dead it seems.

Anyone wishing to try out this add-on without creating yet another login and password can install it from Sitepoint’s own site.