Derik Whittaker

All software projects will amass some amount of technical debt.  This is not a necessarily bad thing; it is just he cost of doing business.  As developers the only thing we can do is try to control/limit the amount of technical debt we build up.

If you agree that all software projects build up some amount of technical debt then should we worry about its accumulation?  YES.  It is the type of debt that is built up and the way in which it is managed that can make the difference in a successful product.

Different ways we build Technical Debt.

• Cutting Corners
  Over the normal course of a project there are going to be times when the team or a developer will be forced to make a tough choice between doing it right, or getting done on time.  It is the classic good vs. evil (good being doing it right, evil being getting it done on time) battle in our decision making process.  The number of times we have to make these type of choices is mind blowing (my guess is that we make it so often we don’t even realize it).  However, these decision are what will mold and shape our project.  If we lean too far to the ‘Good’ side the project may slip and we will miss our deadlines.  If we lean too far to the ‘Evil’ side the project may become a maintenance nightmare and we may still miss deadlines (due to poor code maintainability/extensibility).
  
  When we have to cut corners, it is what we do later that will really make the difference.  If we simply mark the ‘Evil’ code with ‘TODO’s’ or throw it onto some list, hopefully we can revisit that code when we have more time to make life better
  
  

• Lack of Cohesive Design
  Have you ever seen that car the drives down the road where the body is blue, one door is red and another door is green (not to mention the rust spots all over)?  If you don’t have a cohesive design for your project, it will end up looking like that car.  I am not saying that the design even has to be ‘good’, but a consistent cohesive design is better then no design.
  
  This is a form of technical debt.  Every new feature/addition to the project may become a one off.  Creating these one off’s will lead to major headaches later on as well as just poor quality. 
  
  
• Lack of quality Business Requirements
  Most developers have learned over time how to start a new task with the minimal amount of business requirements.  We starting coding and when we hit something we don’t fully understand or know about we make assumptions (this assumes no onsite business expert). 
  
  When we make these assumptions they may turn out to be correct or they may not.  Even if they are correct because we don’t have a full understanding what it is we are doing we will be creating technical debt.
  
  In addition to this because we don’t have a complete understanding of what is needed or expected we will undoubtedly have to revisit this code later to make changes/additions.  When we do this, we may be creating technical debt because if the time is not spent to refactor/rewrite the code we may be slapping poorly thought out changes into our application.  More technical debt.

Different ways we can reduce Technical Debt

• Refactoring
  Anytime we have created any form of technical debt, whether from cutting corners, lack of cohesive design, etc, refactoring is the best way to start removing that debt.  If you can just pick one place to clean up after yourself you will be better off in the long run.
  
  This process may be slow and time consuming but will pay massive dividends in the future.  Oh yea, as we are refactoring, make sure we create tests for our changes if it does not already exists
  
  
• Implementing standards/best practices
  Above I talked about if your project does not have a cohesive design you will be creating technical debt.  The best way to reduce this is to push forward with standards.  These standards may be judged as ‘poor’ by industry experts, but at least the application will be consistent.
  
  Start off by trying to implement either code reviews, or peer reviews.  Try to implement coding standards (don’t make the standard extremely ridge, allow developer freedom).  Most importantly try to utilize best practice design patters.
  
  By doing this you will start removing the technical debt you have accumulated. 
  
  
• Reducing the degree in which we cut corners
  Try to limit the number of times you cut corners. 
  
  If you debating two different options and one takes 5 minutes and the other 20.  Try to lean towards the one that takes 20 minutes if it is a better solution.  However, if doing it right will take 4+ hours then maybe you have to cut the corner.  Just leave yourself some bread crumbs so you can find your way back later to refactor it.
  
  Plain and simple, the less ‘bad’ code you have in your project, the less technical debt you will have.

Thoughts, feedback.  Agree, disagree.  Let me know