Is it ok to have technical debt?

No comments

Sunday, October 31, 2010

Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development. Code debt refers to technical debt within a codebase.

[From Wikipedia]debt - by Alan Cleaver

If you’re doing something that you know that will return to bite you in the ass someday than you’re probably in the “technical debt” department. It can be anything it might mean that no unit tests were written for a feature or that no upfront design was made before coding – depending on the team and project. In fact technical debt is all around us - from missing stages in the CI (Continuous integration) process to quick and dirty coding and missing features.

Avoiding technical debt is close to impossible - unless you are a true craftsman, have a patient and understanding boss (and no deadlines) you might be creating debt as you go along.

But it’s not all bad – because unlike actual debt you might not have to pay interest - some of the time it might actually go away, requirements change or additional code is written and from time to time problem just go away. You might find out that something that was nearly impossible yesterday become easy today just because you’ve learned something new.

I’ve learnt to treat technical debt just like any other known risk  - it should be treated and managed - ask yourself what the worse that could happen – will I pay more on a less favorable time (e.c. deadline) and how much time would it take - and decide if it’s worth not doing it right now.

Having said that – there is a catch, it’s way too easy to use technical debt as an excuse. From time to time I get to hear a fellow developer say something such as: “I won’t be doing X because it would take too long and we’re already behind schedule”. The problem with that statement is that I usually have the feeling that he did not think about the consequences of not doing what might be done – because sometime it’s easier not think about tomorrow. The solution is simple – just ask him: “what would happen if you don’t do it” – and then listen – because he might convince you that creating debt at this place and time is ok.

From time to time you might even convince him that he should do what he’s avoiding right now – and by doing so you’ll make your team better.


Happy coding

Why not do it right the first time?

No comments

Wednesday, October 13, 2010

I’ve just spent the last three hours working with a awful application. It not that it’s a bad application – on the contrary it does what it claims to do but while getting from point A to point B you must pass a world of pain. imageThe app has the default “battleship gray” look and feel – which is only acceptable if you’re in the army, doing the simplest task consists from at least four steps and my favorite of all – no keyboard shortcuts.

I have the feeling I know what the developers of this application thought to themselves – we’re writing a professional, hard core application that is going to be used by highly skilled and well trained users so we don’t need to make a beautiful UI – or maybe they just didn’t care.

Assuming they did care what might be the reason that they wrote all of the needed business functionality but didn’t back it up with simple – easy to add usability? I have seen it happen before you concentrate on providing the best application ever that you forget your users. When the time comes to create the UX you quickly stick together a poorly thought application and hope for the best.

This is ridicules – creating a professional looking application is not that hard – change a few defaults, add keyboard shortcuts and your users will thank you. With little paint you can make your almost-working tool into something that other people would want to try.

Even when creating a simple tool for internal use – think about your users, do you want them to fear and loath your creation – which means that they wouldn’t try new things and would come for you for help with every problem they encounter on the way.

Perhaps we should treat the user experience as a feature – and a technological debt that should be paid now or would come to bite you in the ass later on – and if that doesn’t work remember that your users can decide to use the competitor's tool instead – so treat them well.


I hope never to use such a tool again – unfortunately I know I will…

Related Posts Plugin for WordPress, Blogger...