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!
Bike Shed? In B-school they talk about the Bike Shed problem - where engineers got too bogged down by the complexity of a design issue so they focused on a small part of the overall design, at the expense of the overall project.
I LOVE this idea! Bikeshedding has been added to the publishing schedule, due on 17 Sep. Thanks for the suggestion!
Whoops, had to push this post to 19 Sep due to Labor Day. It's still coming though!
You can start with Scrum, which is currently the biggest software management anti-pattern.
I think you meant to say "bad Scrums are bad." I can't even logic out how less than 15 minutes of your time spent per work day results in bad things happening for you, unless those 15 minutes were spent with your boss as he told you you were fired, and it never has for me throughout my career. On the other hand, I have heard plenty of tales of 30 minute plus Scrums where solutioning and design meetings somehow manage to happen spontaneously. It's not really an anti-pattern if it can be applied correctly, though.
Well if all you are doing is taking 15 minutes a day to sit with the team (or even 30), but not doing anything else scrum related, then this means you're not doing real scrum, and paradoxically that's "why it works" ... the more you try to apply it by the book the more it becomes an anti pattern!
Here's one:
Ever seen a variable named "m_Lock" in a class? Yup.... someone knew they needed locks to protect against concurrency within the application, but they didn't really understand multithreading. They also don't fully understand precisely what they need to protect, or when they need to protect it. So they create a variable and name it "m_Lock" (that way: it is self describing, of course), and make it simply lock everything in every method's body.
...and Presto change-o: your multithreaded problems are now all solved....
Don't you mean Lava Layer, rather than Lava Flow? It's my "favourite" anti-pattern, being the one I have to deal with the most.
No, I definitely mean Lava Flow, and you'll see why in the post.
Great idea for a series - I look forward to reading it.
Not sure which of your categories it would fall into, but I'd suggest "Here be Dragons" - where there's a block of complex code that everyone on the team is afraid of, so they put up a sign "Here be Dragons" (or "Abandon hope all ye who enter here") and stop changing/maintaining that code.
There are lots of variations - sometimes it's a class that implements some very specific business rules (especially if those rules are defined by legislation and "getting things wrong" might result in legal penalties), sometimes it's an entire component, perhaps written by a rockstar programmer who has now departed. Sometimes it's a multi-threaded multi-paradigm spaghetti monster of doom; sometimes it's well written, commented and idiomatic.
Effects include ... nasty bugs that remain unfixed for years ... other components that get severely contorted because new features are added by hacking code that's understood instead of venturing into the "Swap of despair" ... team members who procrastinate because the "simple" fix they've been asked to do is super risky ... code metrics in the "danger" range because every modification is done in the simplest possible way and things are never tidied up or refactored ... projects stuck on outdated, unsupported or insecure platforms because it doesn't work on the newer compiler and no-one understands why.
So I've been thinking about this idea on and off for weeks, but I cannot seem to settle on a way to include it in this series. It is absolutely an anti-pattern, but it's also heavily opinion-based and the solutions vary wildly. Consequently I don't think I can include it in this series. But thanks for the idea, and thanks for reading!
Can't wait.
Suggestion for anti pattern: "Exchanging simple with easy". Examples: AutoMapper and the IOC Container Anti-Pattern (reference: https://www.codeproject.com...).
I'm so excited to read your opinion about cargo cult programming! Looks like a great series, thank you.