Welcome, dear readers, to a brand new Deep Dive series: The Daily Software Anti-Pattern!
I've been working on this series for about a month now, and I'm so excited that I finally get to share it! In this series, we'll talk about a huge variety of software anti-patterns, from Analysis Paralysis to Stovepipe Enterprises, what they mean, and how we can fix them. Plus, there'll be jokes! Lots of jokes A very reasonable amount of jokes!
This time, though, I'm doing something a bit different. I've written up a series about anti-patterns, but I also want your suggestions! I might even turn some of those suggestions into new posts. Keep reading to find out why.
So What's An Anti-Pattern?
In short, an anti-pattern is a common solution to a problem that generally results in counterproductive situations or is simply ineffective in and of itself.
Let's be clear here: I'm being fast and loose with the definition of "anti-pattern" because there's no truly universal definition of what that means. Some anti-patterns related to code, and some to management. Some are easy to define, and some are nebulous, ever-changing. There's no one-size-fits-all definition.
Further, this series is not intended to be all-encompassing. I am not some research god that spends months doing an in-depth investigation before publishing a paper; I am Some Guy On The InternetTM and I like to be entertaining. If you want long, in-depth examinations of these anti-patterns, go check out SourceMaking, they're really thorough and pretty readable.
The Daily Software Anti-Pattern is intended to be a humorous overview of some of the common software anti-patterns we software developers might encounter, and my suggestions (many born from experience) as to how we might deal with them.
Types of Anti-Patterns
The anti-patterns in this mega-series fall into one of four types:
- Software Design: These anti-patterns occur when the design or architecture of a system is incomplete, ill-understood, or just plain non-existent.
- Programming: These anti-patterns appear in the code itself, whether from unnecessary objects, code which is required but not understood, or just plain bad practices.
- Management: These anti-patterns happen when management makes poor or ill-informed decisions, including both too much planning and not enough planning.
- Methodological: These anti-patterns arise from how a team thinks about their projects, and how they react to change. This can include a form of groupthink, a desire to make something their own, or a simple inability to use things they didn't make themselves.
Most patterns fit one of these types, but there are a few that fall into multiple categories.
Publishing Order
I will publish a post from this series every Monday, Wednesday, and Friday for as long as I have posts to publish. Here's the publication order for this series (all dates are in 2018):
The Inner-Platform Effect (15 Aug)
Spaghetti Code (17 Aug)
Not Invented Here (20 Aug)
Analysis Paralysis (22 Aug)
Reinventing the Square Wheel (24 Aug)
Lava Flow (27 Aug)
Stovepipe Enterprise (29 Aug)
God Objects (31 Aug)
Death by Planning (5 Sep)
Cargo Cult Programming (7 Sep)
Big Ball of Mud (10 Sep)
Boat Anchor (12 Sep)
Golden Hammer (14 Sep)
Gold Plating (24 Sep)
Bikeshedding (26 Sep) (Community Suggestion)
I'll update this list when new posts get added. Speaking of which...
Got Any Suggestions?
I wanted to do something a bit different from my last mega-series on Design Patterns, so I'm taking suggestions for new posts about anti-patterns!
Let me know in the comments below about an anti-pattern that you feel should be included in this series, and if I can find enough info about it to write a solid post, I will!
It would be awesome if your suggested anti-patterns fit into one of the four categories above (Software Design, Programming, Management, Methodological) but it isn't a strict requirement; I'm always happy to take suggestions from my dear readers.
Let's Go!
Anti-patterns are incredibly common in the software development world. This mega-series aims to shine a light on them, to talk about some strategies to solve them, and to bring some humor to what might be a very unfunny situation. In short, I want all my readers to recognize these patterns, and be able to take steps to prevent or fix them when they are found in this wild, wild world of modern software.
Check back on Wednesday (or subscribe via RSS or by email) to see the first post in the series. I've had a lot of fun researching and writing this series, and I hope you have just as much fun reading them. You might even learn something.
Looking forward to hearing all of your ideas, stories, and opinions!
Happy Coding!
