Chop it!

The problem of butcheries is that people always look for the fastest way to find a solution. Planning, drawing and thinking is expensive. Butchering is not.
The following match summarize the dilemma of the butcher.
Have something working writing one single wrong line of code in the wrong place Vs Have something working redesigning the code (because something was forgotten when the code was designed the first time) to have an elegant and general solution to the problem.

Well you all know who will be the winner of the match in the butcher's mind.

The problem though is more complex than "laziness" the biggest problem is that the butcher often cannot go for the second solution for one of the following two reasons:

1) He's a butcher, butcher he was born and butcher he will always be. Not really gifted form mother nature the butcher understood since his first days the power of conditional instructions.
IF THEN ELSE...mmm...if this is this then this can be like that.....mmmm and if it's different...mmm ELSEIF! The butcher hardly resists IF temptations and ends up solving the 99% of his problems with an IF. The code at the end looks like a labyrinth. His real problem is that he does not understand designs and in his mind most of them are just hard-to-understand-solutions for problems that in his mind would only require two letters. IF.
OOP butchers are easily recognizable cause of the huge size of their classes. The truth is that butchers are nostalgic people who are missing the old PASCAL school. They create a class called MyApplication and put everything within it. Who said OOP was difficult?

2)The butcher is working in a butcher's shop so he has no way out. The code is chopped and minced as dead meat. He usually joined his company in the middle of the Butchers Summer Festival, the applications looks like a Dali's painting and he doesn't know where to start to tidy up the code. Hard to find an escape from such a place, the developer usually ends up sticking with company's polices.

Programming is an art, and noone could recognize a butchery without having been a butcher himself in the old times. The main problem I think is to catch the right problems. The 90% of butcheries born because of people ask the wrong question when they face a problem. When a developer ask himself the wrong question the wrong answer follows. The wrong answer is called CHOP IT. A lot of times I've heard questions "how to do this" where this was generally a particular something to have the application working in the punctual situation. Posing the question at the right level help people to avoid such situation. So my little advice if you feel like you are going to do a butchery is: ask yourself why you need that. Then ask yourself why you need that that needs the butchery and so on. Moving the problem far from the code minimize the risk of an inappropriate solution. This can't apply always of course but I find it useful in a good number of situations. I'll write more on this topic...Bye now.