In software development there is a concept called TechnicalDebt [1]. This concept relates to the fact that there are two ways of solving a technical problem: a quick-and-dirty way and a clean way. If a software developer chooses the quick-and-dirty way, the developer gets an immediate payoff of advancing through the development process; however, this advancement comes with "interest" payments. The interest, in this case, is the extra effort the developer must expend to deal with the complexities of the quick-and-dirty solution that emerge later in the development process. Most developers dislike TechincalDebt, but, when faced with impending deadlines, they often take on such debt in order to deliver software on time.

The concept of TechnicalDebt is important. What is missing, though, are guidelines on how one can judiciously use TechnicalDebt. To fill this void, and to curb my perfectionistic tendencies, I have recently started to employ a rule that Jim Barksdale introduced to Netscape in 1995 [2]:

"Rule No. 2 is, don't play with dead snakes. When a problem has been solved, or you have taken an approach on something, do not revisit it. Simply move on down the road."

Thus, now, when I encounter a technical problem, I try to solve it in the best possible way (i.e. I try to kill the snake) without going too far (i.e. playing with a dead snake). For some reason, I find this advice very compelling since I don't want the snake to rear its ugly head later in the development process to bite me, but I also don't want to spend large amounts of time overdesigning a generalized solution to a problem that I have already solved.

[1] http://martinfowler.com/bliki/TechnicalDebt.html
[2] http://www.forbes.com/2009/08/05/netscape-venture-capital-intelligent-technol...

Permalink | Leave a comment  »