Even though I wasn’t previously familiar with the term, “Technical Debt” is something I consider for clients every day.

I’ve just read a very interesting article on SitePoint about technical debt, putting it in comparison to personal debt and credit cards.

Technical Debt, a phrase coined by Ward Cunningham in 1992, refers to the negative legacy you leave behind you if you do a poor job of something technical the first time. Maybe the programming was done by someone who didn’t know what they were doing, but you used them because they were cheap. Or maybe the boss was shouting and stamping his feet so the code was written very quickly and not properly tested. Perhaps not enough time / budget was allowed for the architecture planning phase and so the whole system can’t grow as it should.

criAll of these issues – which, to my mind are generally caused by timescales and budgets, although often also by people with a lack of understanding being in the driving seat – create technical debt because it’s going to come back and bite you in the behind! It might be that there are little work arounds you have to do manually which means you’ve got more admin time on a daily basis – and time is money. Or it might be that other work now takes longer as a result of having to work around a work around. Or it might just be that eventually you’re going to have to do it again, properly, so as to be able to move your development on as you need to.

Businesses can carry debt

The SitePoint article points out that businesses, unlike individuals, are generally OK with a bit of debt. Businesses might take out a loan for a new piece of machinery or premises. And so a bit of technical debt might be OK if it meant that at the time you could do something quickly and cheaply which really helped you achieve a certain critical business milestone.

However, on that illusive “rainy day” you should work to pay-back your debt – investing time and/or money into catching up with things so that you’re gradually paying your debt off. If you’ve got lots of debt, David Shirey over at SitePoint recommends you think of it as you would credit cards and pay back the debt that’s going to cost you the most first.

The technical debt balance

Every day in my job I talk to people about new features they need added to their web system, or that they need from their new system. Budget is pretty much always an issue, and there’s pretty much always more than one way to “skin a (web) cat”. Which gives me the task of working out a plan of action which delivers what’s required but to the right price.

Often this involves describing the ideal solution, but then pointing out some ways which could cut costs. Sometimes these are things the client can visualise, such as less things they can control themselves; sometimes they’re more abstract to the client because they’re to do with how the code will actually be written or the database will be arranged so I just need to describe the pros and cons of the outcome.

The client can then weigh up whether they can live without those bells and whistles, or if they’re happy to know that in the future, when they want “Phase 2” added there’s going to be a bit more work involved than there would be if we  had done more in “Phase 1”.

There will be times where a bit of technical debt, in it’s strictest sense, is absolutely fine – there are instances where “academically” you should do things a certain way, but you just know that in reality that is going to take 3 times as long as another way and cost the client 3 times as much, whilst the other way would never actually cause them a problem. Maybe this doesn’t even count as technical debt because it doesn’t actually cause a problem?  I’m not sure – I’m new to the term. But I do think that you always need to consider the long-term ROI of any development hand in hand with the health of the system as a whole.

Where things can go badly wrong, I think, is where the customer isn’t aware of the technical debt they’re amounting. They might not realise that they’ve chosen an inexperienced developer who is making a hash of things behind the scenes. They might not be reigned in by the eager-to-please account Director who is saying yes to every ridiculous time constraint thrown at them whilst the tech team are saying the system is creaking at the seams. Worst of all, is where they’ve been told all along – they just haven’t listened.

It’s vital that if you have a website or any kind of system, you engage – at some level – with the technical side of it. You may be scared of being inundated with technical jargon, but just make sure you’re working with a company who can explain things to you in normal-speak(!) and can help you weigh up the pros and cons of certain decisions and actions so that you can run your business as you need to.