Software debt – another type of rot

by daniel on March 7, 2009

Since software is a solution to some requirement, software evolves, the same way as requirements evolve. This is true for games, commercial applications and open source projects. This evolution comes with a cost, as so well described by Jeff Atwood. For me, the process is very familiar because it occurs in almost any project with a large lifespan.

While the post itself is interesting, some of the comments were enlightening, mainly on how people fail to see the problem. Specially this comment:

This post pretty much boils down to “we have to refactor/rewrite some stuff on our software project” – Big deal, so do I; and probably so does the poster above me, and the one above him.

Details Jeff, is what makes a technical article… technical. Otherwise this could have been written by a 2nd year business major.

The problem is not that you have to refactor/ rewrite. The point of the article is that refactoring/rewriting is part of the process, of understanding the why .

The reason code rots or accumulates software debt varies, but has some very simple reasons:

  • The requirements change
  • The design is rushed / non existent
  • The development is rushed
  • The testing is rushed / non existent
  • Code fashion changes

Any of them or a mixture will cause software debt, and almost all of the reasons will apply in a larger project. Thus you need to take into account a refactoring phase that can sometimes be large as an architectural change. Because most of the refactoring occurs after the original code has been long used we as programmers see it as “WTF” who wrote this, forgetting that it might had some real reason long ago.

Laugh all you want of previous mistakes, you will make your own mistakes mainly because requirements change.

Comments on this entry are closed.

Previous post:

Next post: