Elastic-, plastic- and fracture characteristics of code

I recently had a post about technical debt, and Jelena made a very insightful comment that it was like elastic, plastic and fracture characteristics of materials like steel. I started to comment on the comment, but eventually I thought it deserved its own post.

My reflection is that depending on what strain the code is under, according to Jelenas suggestion, that could be a guideline for what strategy to use:

The code can be refactored in small steps in a continuously functioning system. Problems are reversible. Sometimes you have to refactor into submission [1].

The code has suffered from to much neglect to be reversibly refactorable. It might be better to apply the strangler approach [1].

The code is really broken and every attempt to fix it makes it worse, or cost a fortune. Rewrite and throw away [1]. Warning! This is a risky path for a lot of reasons, and you are seldom in such a mess. Consider this to be the “nuclear bomb” of refactoring.

[1] http://www.exampler.com/old-blog/2005/05/11/ Brian Marick concludes the important remedies.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: