A couple of ex-coworkers at a place I did a contract at complained about my code during recent maintanence of theirs. They say it is "overfactored", and too hard to figure out where to make changes.

However, I tend to find their style under-factored. You have to figure out all the different places to make the same changes over and over. And they use Fortran-style arrays instead of more modern things like hash arrays and database tables.

I think under-factored code is appreciated over heavier factoring because the changes you make are incrimental. In high-factored code you have to kind of grok the abstractions first before you can do anything. However, low-factored code you can often scan through it and make the changes incrementally. You may have to make the same change in multiple spots, but at least you feel the steady progress as you attack one duplicated portion at a time. But, there is no abstraction framework to have to grok.

Your fingers might work harder, but your mind works less. I suppose other people's abstractions can be a little weird. I've encountered some doozies myself.

Now, if only he could take the logical next step...

OO is a reversion back to the 1960's "navigational" databases. OO proponents say that OO is better than the navies of the 60's because behavior is "integrated" into it, but in my experience the relationship between nouns and verbs is often many-to-many over the long run, not one-to-one like ADT-like philosophy assumes. (Maybe for low-level device-driver-like things it holds to some extent, but not for business entities.)

Anyhow, as far as complaints about too many subroutines and abstractions in my code, when in Rome do as the Romans do. Fighting the "system" is a dead end career-wise. Companies don't want to be "fixed". (Nor do OO zealots :-)