I've seen multiple variations on this article over the years--it usually seems to be directed at Java, and it usually involves solving a very simple problem wit

I've seen multiple variations on this article over the years--it usually seems to be directed at Java, and it usually involves solving a very simple problem with the "full stack" of Java (anti-)patterns. I've coded professionally in static and dynamic languages, and enjoyed myself in both worlds for different reasons (I guess I just enjoy coding on a basic level). I recently came back to Java after a multi-year hiatus, and suddenly found myself back in a world where people tend to program in patterns such as the above. The funny part is, my experience has ultimately been positive. I was recently in the position of having to patch and modify a very large Java library (written by some well respected Google guys) because I needed it to do something different from its original intent. The OP would have hated this library--when I cracked it open I found innumerable factories, strategies, observers, visitors, etc. etc. After studying the library for a while (which was frustrating because as a developer I wanted to just dive in and write some code), I started to realize that the patterns were well-utilized and built with anticipation of expansion. In the end, I was able to inject my code into the midst of the patterns at some key strategic points and make fundamental changes to the library. Most importantly, I did so feeling like I had the implicit blessing of the developers, and that the general algorithmic flow of the library was not impacted. What I've found after my return to Java is that the language is so boringly, stultifyingly structured that an amazing thing happens--you can actually weave together an application with thirty dependencies on other libraries and have it work. Libraries aren't walking over eachother and behave in predictable fashions. Developers aren't dynamically injecting code into core libraries because they can't. Now, the library I was patching was the kind of library that deals with real world server-side complexity (managing data across multiple stores, with support for testing environments, etc.). That's where these types of patterns shine. They don't shine in examples like the OP's. If a developer in my organization always wrote code like that, I would hope they would be let go. But if they wrote code like that where it was needed and useful, I would be quite happy with them! Conversely, if a developer thought such patterns were never necessary and were never useful, I would think they needed to learn their craft a bit more. In the end, it's all about pragmatism and experience. Over the years I've been bitten for over abstracting and under abstracting. Over the years you develop a weather sense for how extensible a particular piece of code needs to be.