Technical Debt

http://danube.com/system/files/WP_Technical_Debt.pdf

 

 Expectations at the start of a project

 

 

Reality has a way of making its presense known

 

 

Pressure is placed on the project team to be more efficient

 

The difference between what was delivered and what should have been delivered is known as technical debt.

 

 

Cruft on Cruft

 

 

 

 

 

Cruft (n):

1. An unpleasant substance. The dust that gathers

under your bed is cruft; the TMRC Dictionary correctly noted that attacking it with a broom only produces more.

2. The results of shoddy construction.

 

 

Legacy System (n):

A computer system or application program which continues to be used because of the cost of replacing or redesigning it and often despite its poor competitiveness and compatibility with modern equivalents. The implication is that the system is large, monolithic, and difficult to modify.

If legacy software only runs on antiquated hardware, the cost of maintaining this may eventually outweigh the cost of replacing both the software and hardware unless some form of emulation or backward compatibility allows the software to run on new hardware.

(Free On-line Dictionary of Computing, www.foldoc.org)

 

 

As a developer, nothing was more challenging and frustrating than to be added to a project late in its development. Working with code afflicted by technical debt made me feel like an archaeologist trying to clean up an artifact that will crumble unless I work slowly and cautiously.

 

 

Even if a manager has difficulty recognizing the value of repaying debt each Sprint, he or she could hardly argue against the potential cost of rewriting a legacy system from scratch.

 

 

Large amounts of technical debt must be made visible as first class Product Backlog Items, to be split many times and prioritized along with the business stories. If stakeholders can’t see why they should be concerned, it is doubtful they will want to allocate a team’s effort toward an activity that does not visibly move a project forward.

 

 

How to Survive Technical Debt

 

 

The only way to ensure that developers - and organizations

- do not find themselves in a similar situation is to incrementally add automated tests. Not only does this increase velocity, it also reduces risk by preventing

developers from “flying blindly” as they make changes to the code base. While it’s unlikely that an organization can afford - in terms of time or money - to implement all of these tests at once, an organization

should prioritize the test coverage to cover areas where it is most needed and incrementally add more tests as more business functionality is introduced

 

 

PS:

If can not see the picture, please see how to access picasa at:

http://blog.fufuok.com/Article/google-picasa-hosts.aspx