Even this isn't the problem; I generally prefer the style (in Java at least) of splitting things up into small pieces, pkolaczk below gives some more rationale.

Even this isn't the problem; I generally prefer the style (in Java at least) of splitting things up into small pieces, pkolaczk below gives some more rationale. It's certainly easier to test, and is often easier to read. But yes, people can go way too far with it, leading to the infamous pejorative "ravioli code". And people can pervert it, e.g. in the name of expediency creating paranoia by wrecking previously simple and clear functions by editing in functionality that function shouldn't be handling and violating the principle of least surprise. Few things hurt as much as getting relaxed in a codebase, able to skim over most function calls that aren't relevant to the problem you're looking at, only to then be tricked by an innocuously named method along the code path doing what it shouldn't and wondering if you need to start inlining (mentally or otherwise) everything to avoid future trickery. Terseness that comes from powerful expressions (simple SQL queries can replace lots of code in any language) is great, though terseness just in the form of density shouldn't necessarily be a goal. At my last job the worst Java code was the most dense, with huge methods spanning hundreds of lines and sometimes up to 10 levels of indentation. Sure it's all there, but it's hard to understand everything it's doing (and more importantly why), impossible to cover with good tests, very difficult to refactor because of so many implicit dependencies you have to untangle first (and there are higher priority items), no justified pressure against "just adding one more conditional" to the middle of some big method to satisfy some new requirement from somewhere (so long as the tribal knowledge exists about where such code ought to be placed anyway, it'll take anyone new a long time to find out from scratch), and so much dense code in many core infrastructure areas was initially written by a superstar coder over a decade prior -- if he ever left the company, a lot of things would break with no one to fix them in a reasonable amount of time, he has so much institutional knowledge and no time or pressure to document it all if such a thing were even possible. Out of control ravioli code on the other hand was relatively easy to wrangle back under control -- my favorite was a huge logging framework written by a Principle level employee that actually wasn't used by anything, not even its supposed log() entry point, so it was just a big no-op, and could be deleted. The hardest parts of maintaining software aren't the difficulties in understanding a clever piece of code using advanced language features, but just the sheer complexity of computation being expressed. This is part of the essence that has even a few old time Lispers saying things like "language doesn't really matter" -- nevertheless, I think CL pressures reduce complexity and difficulty of understanding more so than Java, and still decades later has better tools to pierce the veil when understanding is difficult. (Monitoring tools, not as much, though well-understood code tends to not need as much monitoring.)