Technical Debt

I was on my way home tonight on the train and was feeling bored. So I whipped out my Google G1 phone and starting reading Jeff Atwood’s Coding Horror blog. He posted a very interesting entry that talks about technical debt, read all about it here. He is the second person I know that used this term, last person that mentioned to me what technical debt is was one of my ex-colleague almost 2 years ago, so it’s not something new.

In a nutshell, technical debt is a kind of debt you incur everytime you do “something wrong” in code. Whenever someone implements a quick and dirty approach, or copy and paste existing code..etc, you incur a debt. It does not matter how big or small the dodgy action is, the debt builds up over time. Like all debts, you incur interest, meaning it becomes more difficult to do the simplest change, or build/extend features over the existing codebase. In every project, there will be some level of technical debt, and it lessens with refactoring, or rework of code. When the debt reaches a point when there’s no way to pay it off, it might be easier to rebuild the application from scratch.

Everyone of us are guilty of writing dodgy code, or seen dodgy code and left it dodgy. One of the worst things in my opinion is what I would like to term as the copy-and-paste syndrome. This behaviour typically involves someone looking for existing code that will be fit for his/her use. It begins with a left mouse click and hold, drag and highlight, a Control-C, followed by Control-Tab perhaps, finished with a swift Control-Z. Viola, that was too easy, no thinking required, and job done!

Of course I have done it before too, and I’m not proud of it. However at least make effort to see what you are copying and pasting. You might be copying a bug over to your code! There can be exceptions to this syndrome, like when you copy and paste HTML for pages, but that’s about all I can think of. If you see a block of code that can be reused, refactor it to a helper class so that it’s encapsulated. One of the first things I do on every project start-up is to define a common library, create helper classes, build a constants file; that way future additions will be centralized and encapsulated in one location. We should always strive to eliminate code duplication, less code = less effort to maintain, so Dont’ Repeat Yourself!

Thinking hard about how to reduce technical debt, I believe it’s a joint effort from the team. Here are some of the approaches I have experienced and found valuable:

  • More communication amongst team members. That means no headphones while working. When a team member raises an issue, everyone participates in the discussion. (A whiteboard in the room is a must for the development environment). When someone write a reusable component or code, an email or verbal annoucement is made, so everyone knows about it, to avoid code duplication.
  • Daily stand-ups. I find this to be very valuable. Everyone gathers every morning to report about what they are working on in a brief 3o seconds or so. This allows everyone in the team to know what everyone else is working on. You might tell the team you are encountering problems writing a complex Stored Procedure, and the DB guru in the team can help you out. A stand up is also called a stand up because it should be done standing up, reason being that it’s uncomfortable to stand for long periods, so people don’t blabber on and on about their personal life, about a movie they watched last night….blah.
  • Design session weekly or fortnightly (during lunch time if possible, and get your Project Manager to pay 😛 ). The team discuss about issues, and possibly come out with proper design solution. Might be helpful to get everyone to come out with a list of issues for your first meeting, compile it and get everyone to rank each one by priority. Each item gets looked at every session. Also appoint a chair person to resolve conflicts and disagreements, as they always will be.
  • Pair Programming. I did pair programming for a short period, and I loved it. It involves two programmers work on one machine, one person drives and the other person observes. The observer can spot problems in code, or even initiate discussion about how to implement it better. It’s almost like refactoring, coding and defect fixing happening all at once. After a set number of hours, the pair switch roles and the process continues. I found myself to be more productive in pair programming, and the end result is a better, cleaner implementation. Need for rework is less, and code quality is high.
  • Unit testing, unit testing, unit testing. When you find writing unit tests for your code is difficult, that tells you a lot about your code. That is an indicator that your code is highly coupled when you have problems testing a class and have no way to mock the dependencies. Start unit testing from the beginning, and you will reap the benefits every single day.
  • Flat organizational structure. In an ideal world, it should be flat. No one is better than anyone, and using your experience or role to overwrite someone else is strictly prohibited. Every team member is responsible for the application’s design and implementation, not one person. See if you can make things flat, and if you do, do let me know how you achieved it 🙂
  • Speak up! I feel this is so important. Most of the developers I met always keep to themselves and just do what they are told. Talk to your peers, participate in discussions, and you will learn much more than you can ever learn from reading a book. The more you know, the better you become, and in return you impart your knowledge to others. I always believe the technical skills and ability of a team is only as strong as the weakest member.
  • Have a Retrospective every fortnight. This is one of my favourites things, but unfortunately I don’t get to do this in my current workplace. A retrospective is basically a session where the team sits together and reflects on the things that happen for that period. Every member gets to speak about something good and bad that happened. You can take this opportunity to commend a fellow team mate who wrote a fantastic component, or coming up with a superb idea for a complex problem. It’s an opportunity to give recognition when deserved. You can also talk about something bad, perhaps how the Build (Continuous Integration) takes forever to compile, or how we are not writing sufficient unit tests…etc. When something bad gets noted down, someone will volunteer or be nominated to look at it, and report the status on the next retrospective.
  • This is to all Team leads and managers, you are the people that can bring the team up, and also lead it to chaos and destruction. Lead the way, introduce processes that help. Lead in the application design, start peer reviews, implement unit testing, put continuous integration in place, perhaps even introduce pair programming. No programmer I know will enjoy working with high defects count, or working with a codebase that takes days to do a simple change. It all depends on the leads and managers to start the right processes and practices early, and not when there’s nothing left to salvage.

Technical debt is always present, just a matter of how much you owe, and you always end up paying for it. Ka-Ching $$$$

Share this post : it! digg it! dotnetkicks it! live it! technorati!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: