That's all folks! Thanks for reading my new mega-series, The Daily Software Anti-Pattern. I had a TON of fun writing this series, and my hope is that it was useful, insightful, or at least amusing for my readers.
I wanted to close the series with some thoughts that occurred to me throughout the last few weeks in which I was publishing these posts.
"Bad" Is Subjective
Several of the commenters on posts in this series have pointed out, correctly, that many anti-patterns are a matter of opinion, or else aren't clearly defined. That is an inherent problem with the idea of "anti-patterns": what's "bad" is more subjective than what's "good".
Put a bunch of people in a room and ask them to determine what "bad" and "good" are for any given problem set, and I'll bet you'll get far more consensus on what the "good" is than the "bad." This is because the very nature of a problem is that a solution exists. How that solution can be used, whether it fulfills the necessary requirements, and other criteria are what separate bad from good. In other words, "good" is a goal, and is usually more defined than all the possible ways to not meet that goal.
The point of this mega-series is not to discover what is and is not within the bounds of the anti-patterns described, but rather to bring awareness of the terms and, hopefully, some level of awareness as to what might be included in each anti-pattern.
Hindsight Is Necessary
A commenter on the Inner-Platform Effect post and another on the God Objects post both hit on the same idea:
My experience: god objects are not designed in first place, but they are growing into the god object state. Every time the developer has to implement a new feature, it is added in this class, because hey all the data is already here and it is quite easy to add it. Because it is just a new method and a new attribute. Splitting the responsibilities just for this feature would be exaggerated. And some features later you have this class which knows everything and does everything...
In case when you are building a system that is then used as a platform for other systems - then building a platform like thing isn't a bad thing. And there are many cases when building complex platform like thing is the right choise (sic). So I think it is really hard to look at the code and say - this is the inner platform effect. This can be told only after knowing project history.
Very often, anti-patterns can only be identified after-the-fact. No one sets out to write something that falls into an anti-pattern; they only do so accidentally and without malice. Because of this, anti-patterns can very often only be pointed out after they have already occurred.
It's (Probably) Happening To You. So?
If you read this mega-series and thought "these anti-patterns are so general, I need more specifics to determine if one is happening to me," then it most likely IS happening to you. That doesn't mean you need to do anything about it, or at least, not right this second.
The problem with anti-patterns is not a lack of solutions but rather a lack of awareness. Merely being aware that something might be considered an anti-pattern is the first step to being able to solve it when that time comes. After all, you need knowledge and awareness to formulate coherent solutions.
This Is A Blog
Remember that ultimately this a blog, and specifically my blog, and therefore all posts within are subject to my biases, thoughts, and general stance on things. I encourage all of my readers to think for themselves; I am expert on nothing but my own problems, and even then I could use a little help sometimes.
...What?
...Fine, OK, a LOT of help. Happy now?
Anyway, thank you so much for reading my posts. I truly, truly appreciate it.
We now return you to our regularly-scheduled Exception Not Found.
Happy Coding!
