Fear of small methods
I've just started reading Michael Feathers' Working Effectively With Legacy Code. One of the points that Mike makes at the start of the book is the impact that the fear of changing code has in degrading the quality of design -- specifically, how this fear is heightened in areas of high code reuse. Developers working on complicated legacy (aka untested) code engage in what he calls cheekily calls Edit and Pray.
At ThoughtWorks, I get to read a lot of code from different sources: code submission are a part of our interview process and, as a consultant, I've moved between a variety of different projects. One common code smell is long methods. This always struck me as odd as the advantages of small methods seem readily apparent. I previously chalked this up bad habit up to laziness or inexperience or lack of adequate tool support; however, reading Mike's book has given me a different perspective:
Many people regard introducing methods primarily as a form of code reuse (rather than as an aid to readability). Reused code is code that is scarier to change because it is much harder to tell what the impact is of changing it. On the other hand, when your code is all in one long method, it is clear from the scope that the code can be used in that method alone. Therefore, the fear of changing potentially reused code can be a disincentive to introducing new methods (especially in languages without access modifiers). I don't know if any of the writers of these long methods actually think this way, but it is an interesting perspective.