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.
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
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.
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
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
Different ways we can reduce Technical Debt
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
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
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
05-25-2007 9:03 AM