Poorly Factored Code

Just what is meant by PoorlyFactoredCode? It seems that the term is used to describe code that works, but does not work well or in all cases. Just what is the measurement that determines the deficit in code?

I'd call code "poorly factored" if it does what its supposed to, but in a redundant or difficult-to-understand way. (In other words, it scores high on the XpSimplicityRules rule #1, but low on the rest). If it doesn't even do what it's supposed to, then I'd call it "Broken".'

As I understand refactoring, PoorlyFactoredCode works, but it's hard to work with. I think it breaks down to two separate issues:

Understandability What's that MartinFowler line? [Paraphrasing here] "Any idiot can make code a computer can understand, it's hard to make code a human can understand."

PoorlyFactoredCode is code that does the job, but it's hard to maintain, tricky, or undocumented. Even if I understand the language, it hurts my head to read the code.

Ease of Alteration Hopefully, your project will survive. Hey, it might even get to Version 2.

Poorly factored code makes it hard to make changes. You end up relying on IndespensibleGurus? who write obfuscated code in order to ensure their job security (An AlarmBellPhrase if I ever heard one).

If you can't add a new feature without breaking something or making widespread changes in your code base, then your code is poorly factored.

"It's hard to know, it's hard to change." --SeanOleary

Reliability If your code is poorly factored, changes will repeatedly impact many distinct areas of it, and bugs once fixed will have a greater probability to appear again elsewhere.

Courtesy Poorly factored code is tedious to read and boring. This is where one initial developer's inability can hurts the maintainer's intelligence (or patience).

There's a negative feedback loop here :

less factored code => you should pay more attention to impact of changes

less factored code => boredom and natural lack of attention due to repetition

--ChristopheThibaut