How to draw a tiger with just 3 lines?

Question

Background:

An art teacher once gave me a design problem to draw a tiger using only 3 lines. The idea being that I study a tiger and learn the 3 lines to draw for people to still be able to tell it is a tiger.

The solution for this problem is to start with a full drawing of a tiger and remove elements until you get to the three parts that are most recognizable as a tiger.

I love this problem as it can be applied in multiple disciplines like software development, especially in removing complexity.

At work I deal with maintaining a large software system that has been hacked to death and is to the point of becoming unmaintainable. It is my job to remove the burdensome complexity that was caused by past developers.

Question:

Is there a set process for removing complexity in software systems - a kind of reduction process template to be applied to the problem?

Answer 1

Check out the book Refactoring by Martin Fowler, and his http://www.refactoring.com/ website.

Robert C. Martin's Clean Code is another good resource for reducing code complexity.

Unfortunately, the analogy with the tiger drawing may not work very well. With only three lines, a viewer can imagine the rest. In a software system, all the detail has to actually be there. You generally can't take much away without removing something essential.

Answer 2

Check out the book Anti-Patterns for a well-written book on the whole subject of moving from bad (or maladaptive) design to better. It provides ways to recover from a whole host of problems typically found in software systems. I would then add support to Kristopher's recommendation of Refactoring as an important second step.

Answer 3

Checkout the book, Working Effectively with Legacy Code

The topics covered include

• Understanding the mechanics of software change: adding features, fixing bugs, improving design, optimizing performance
• Getting legacy code into a test harness
• Writing tests that protect you against introducing new problems
• Techniques that can be used with any language or platform—with examples in Java, C++, C, and C#
• Accurately identifying where code changes need to be made
• Coping with legacy systems that aren't object-oriented
• Handling applications that don't seem to have any structure

This book also includes a catalog of twenty-four dependency-breaking techniques that help you work with program elements in isolation and make safer changes.

Answer 4

While intellectually stimulating, the concept of detail removal doesn't carry very well (at least as-is) to software programs. The reason being that the drawing is re-evaluated by a human with it ability to accept fuzzy input, whereby the program is re-evaluated by a CPU which is very poor at "filling the blanks". Another more subtle reason is that programs convey a spaciotemporal narrative, whereas the drawing is essentially spacial.

Consequently with software there is much less room for approximation, and for outright removal of particular sections of the code. Never the less, refactoring is the operational keyword and is sometimes applicable even for them most awkward legacy pieces. This discipline is however part art part science and doesn't have very many "quick tricks" that I know of.

Edit: One isn't however completely helpless against legacy code. See for example the excellent book references provided in Alex Baranosky and Kristopher Johnson's answers. These books provide many useful techniques, but on the whole I remain strong in my assertion that refactoring non-trivial legacy code is an iterative process that requires both art and science (and patience and ruthlessness and gentleness ;-) ).