Jump to content

Talk:Anti-pattern/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Eco Codding / Cryptic naming

Plugging in "Eco Codding" to Wikipedia, I get no results other than this page. Therefore, I've removed it. Perhaps it was just mispelled, but I can't determine what the correct spelling is, if so. --Dyfrgi 19:18, 14 June 2006 (UTC)

  • PJTraill 22:01, 16 July 2006 (UTC) — I'm not entirely happy, as the (always unsatisfied) link was originally "cryptic code", then to "eco code", then "eco codding" (coding?). And the description ("Using abbreviatures in variables or functions instead of complete (self-descriptive) names") does describe a recognisably bad solution to a problem, though it could be corrected and tightened up as "Using abbreviations instead of complete (self-descriptive) names". But I could not find anything useful under those names by googling with antipattern OR anti-pattern OR "anti pattern". In fact I googled several things (ee.g. "cryptic", "naming", "name", "abbreviation") with that and got nothing conclusive (but plenty of quotes from versions of this article). I think the anti-pattern tries to solve two problems attributed to excessive code size:
    • difficulty of producing code (better solutions: learn to type, use an IDE, cut and paste the name),
    • difficulty of understanding code, specifically: of appreciating the overall structure at a glance. This is more plausible, and an article on when this is reasonable would be useful. But perhaps a pattern for naming would be even more useful.
      • Actually, we are talking about Design patterns here, not about Coding mischiefs. It's not really the same thing, as if someone cares to actually make a design, variables have less cryptic names because they weren't created on a whim. It happens when there's no design. --Ruijoel (talk) 09:10, 21 November 2007 (UTC)

DLL-hell and code smell

I wonder if DLL-hell and especially 'code smell' belong in here? Fine entries and all, but IMHO they are not really general enough to belong to anti-patterns.

Yo-yo problem

I noticed the Yo-yo problem article, and considered that it was borderline antipattern. I have added the link, but I realise that some might not consider it general enough to qualify as an antipattern. Any thoughts?

- I have encountered that problem ALOT. It definately should be there. Inheritence dependency is a serious issue i think.

I smell an article footer box opportunity here. If anyone wants one, I would be happy to make one for the Anti-pattern series of articles. Shoecream 04:47, Mar 18, 2005 (UTC)

Sure, go ahead. Graue 17:27, 25 Apr 2005 (UTC)
After looking over policy and noticing a category called Anti-patterns, I think that the category serves a pretty good purpose already and a footer box is not required. This also brings up a point: is the big list of anti-patterns really neccessary, if there's a category? —shoecream 23:33, Apr 26, 2005 (UTC)
By now, the list of anti-patterns has acquired extra value, in the form of the brief explanations. And that raises another question: is there a chance of extending the category mechanism to make this happen there automatically? I.e. that where an article specifies its membership of a category it can also supply a brief description to appear in the automatically generated list of members of a category. PJTraill 18:13, 5 March 2006 (UTC) Even nicer(?): A perfectly general 'instance of' mechanism allowing one to specify that the subject of an article is an instance of the subject of another article. And goodbye to the specific category mechanism: everything can be a category. PJTraill 18:20, 5 March 2006 (UTC)

Double-Checked Locking

Double-Checked Locking is not a anti-pattern. It can be made to work correctly(even with multi-processors). It's not because someone doesnt know how to use something, that it should mean it is an anti-pattern.

I agree, it's really not an anti-pattern at all. More just a gotcha. I'm going to remove it, hope nobody minds... --Etoastw 14:41, 30 January 2007 (UTC)

Object cesspool

I added this one after discovering a VERY nasty problem with a hand-made C++ object pool that was supposed to be a wrapper for ADO transactions.

The nasty little creature would run a transaction that did not commit, and the object would return to the pool while still in a transaction state from a previous use. Eventually as the object is reused, the instance would die and a HUGE rollback would occur when the object was torn down or errored out.

Fenceposts is not an anti-pattern

What is the fenceposts problem doing here? This is clearly a bug, and has nothing to do with patterns. Even the best programmers, coding wonderful pattern-based code, run into trouble with fenceposts. -- 84.159.227.16 09:46, 25 November 2005 (UTC)

PJTraill 13:25, 28 November 2005 (UTC) Surely this is a coding anti-pattern, whereas most are design anti-patterns, and a few are management etc.
Perhaps you don't understand the difference between an anti-pattern and a bug. An anti-pattern is a flawed design scheme which may result in code which is functionally correct but difficult to maintain or likely to introduce bugs in the future. A bug, like fenceposts, is something which is functionally incorrect but not the result of a bad design. At best you could argue that the prevalence of certain types of bugs indicates that the language itself has design flaws. -- 67.188.119.42 07:25, 15 January 2006 (UTC)
You're right, taken the words out of my mouth. Let's get rid of it. -- Smjg 12:11, 20 January 2006 (UTC)
On reflection, I agree in this case, though I still think that the concept of anti-pattern is general enough to apply to coding as well as to higher-level design. And a fencepost error is still not just a bug, but a particular way of introducing a bug. -- PJTraill 01:06, 20 February 2006 (UTC)
You misunderstand. Nobody is claiming that coding versus design has anything whatsoever to do with the distinction between a bug and an anti-pattern. The difference is exactly as 67.188.119.42 has put it. A fencepost error is a kind of bug, i.e. it directly causes the program to malfunction. Anti-patterns don't - but they may indirectly lead to errors, in both design and coding, that may cause the program to malfunction. -- Smjg 11:09, 20 February 2006 (UTC)

Empty Subclass Failure

Does this belong here? I'm not a Perl expert but it sounds more like a garden-variety bug than an anti-pattern. Since this has a redlink, which is discouraged, and there is no article for "Empty Subclass Test", maybe this should be removed. Does anyone want to make an article explaining what this is and why it is an anti-pattern and not just a common bug? —The preceding unsigned comment was added by 67.188.119.42 (talk • contribs) 15 January 2006.

One of the foundations of OO programming implies that extending an object, of itself, does not change behavior. There are few languages where the exact type is readily available, and Perl is one of them, so this happends most often in Perl. Nevertheless, it is *not* Perl specific. —The preceding unsigned comment was added by 12.117.131.6 (talk • contribs) 17 October 2006. y are u not a pearl expert

Source of the term "Anti-pattern"

Did the term come from the GoF book, or from the AntiPatterns book? I seem to recall the latter; I'll check the GoF book when I get home tonight. --EngineerScotty 01:20, 20 January 2006 (UTC)

Now that you've reminded me... I checked the GoF book as well, and can find no mention of antipatterns--in particular, in the index. Go ahead and change it. I don't own the AntiPatterns book.

The WikiWikiWeb page AntiPattern has some history over the development of the term--it does appear to precede the Anti-patterns book (which was published in 1998). One anonymous claimant has Andrew Koenig originated the term. Michael Ackroyd appears to have the first reference to anti-patterns in the literature. It is unlikely that the source of the term will ever be conclusively known.

--EngineerScotty 18:36, 5 March 2006 (UTC)

As one of the authors of AntiPatterns, I can only offer that I heard the term "AntiPattern" first from Michael Ackroyd in a presentation he gave at Object World (I think it was in 96).--SkipMcCormick 22:17, 20 August 2007 (UTC)

I've found two references that point to earlier Koenig's publication (March/April 1995). Added the reference to this article. I found out that in the article itself Koenig states that he is an inventor of the term antipattern. --Kubanczyk (talk) 14:44, 11 April 2008 (UTC)

DLLs are MS-specific

I have re-inserted the allusion to MS in the explanation of DLL hell, as the article is pretty specific, as is the term DLL. Of course the concept is more general, and is perhaps better covered by Dependency hell, which I have added, though that article is pretty specific to Linux .. and maybe we should mention Extension conflict. PJTraill 17:19, 12 March 2006 (UTC)

Pitfalls are not anti-patterns: make room for both

PJTraill 12:19, 9 April 2006 (UTC) A few thoughts:

  • Principles
    • Pitfalls are not the same as anti-patterns, but there is a lot of overlap.
    • Both occur in recognisable situations, and both have the "recognisability" of patterns.
    • An anti-pattern implies a particular (wrong) solution, whereas a pitfall can mean a family of mistakes.
  • Organisation
    • Separating pitfalls from anti-patterns would probably be couterproductive.
    • A separate category for pitfalls might well be desirable.
    • Many of the "anti-patterns" linked from here are better classified as pitfalls. We could tag them as such.
    • This would bring a few links back into the article, such as fenceposts (a pitfall, not an anti-pattern).
    • It would be going too far to add highly language-specific mistakes, we want things at a fairly conceptual level.

Cash Cow isn't an antipattern

Making lots of money by selling something at a cost far more than you paid for it is ideal for business practice. It's only when management ignores threats to their cash cows and don't take steps to mitigate that they have a problem. Joncnunn 16:31, 27 April 2006 (UTC)

Removed "software never gets released syndrome"

I removed the entry for "software never gets released syndrome"; there is no such anti-pattern defined in the literature. While the problem of neglecting test/QA up front leading to massive schedule slips at the end (the result of a shoddy product being delivered) is well known, it isn't known as this. This page should only include well-documented antipatterns; not ones that you make up yourself.

If you want to suggest a new anti-pattenrn; I suggest you visit WikiWikiWeb [1] instead. Even though they're not a major patterns site these days; they (we!) still enjoy a few new good ideas along these lines. And not being an encyclopedia, WikiWikiWeb loves original research; whereas WP:NOR is firm policy here at Wikipedia. --EngineerScotty 05:28, 14 May 2006 (UTC)

Social anti-patterns

Improv: Zap a section that would make a good textbook definition of POV [2]

I added the section again because the explanation for removal is insufficient (IMHO). --Fasten 12:23, 19 May 2006 (UTC)
Here's a better explaination for why the "social anti-patterns" section should be removed from this article: They're off topic, and largely irrelevant to the (somewhat academic) topic of "anti-patterns" as discussed elsewhere on the page. The notion of "anti-pattern" has its origins in software engineering and software engineering management, which is why the other two categories of anti-patterns all concern things that happen at IT shops. While the term "anti-pattern" can be extrapolated to negative or counterproductive behaviors in other domains (including politics and sociology), such usage is rather informal. The use of the term anti-pattern in the software engineering context is well-established in the literature, and can be demonstrated with reliable sources, starting with the AntiPatterns book. Your extension to social issues is, at best, original research.
Further, User:Improv is correct; you list is WP:POV. I agree with your opinions on many of them; but many of the topics you address are controversial ones for which you will find many opponents. For example, many people support laws opposing mind-altering drugs and prostitution, and consider these to be beneficial to society, and would disagree with your claim that victimless crime is an anti-pattern.
At a minimum, for anything on your list which is disputed, the dispute should be addressed. Anything which isn't discussed as an "antipattern" in the literature should be removed. To use victimless crime as an example: I typed +antipattern +"victimless crime" into Google [3], and came up with five unique links. Two of them were unrelated commercial sites likely engaging in keyword stuffing, one was slide presentation which happened to contain the two terms out of context, and two were Wikipedia mirror sites' presentations of this article. Clearly, declaring victimless crime to be an Anti-pattern is a neologism at best, original research at worst. In either case, it doesn't belong in Wikipedia.
I vote to strike the whole section, for the reasons above. --EngineerScotty 17:11, 19 May 2006 (UTC)
PJTraill 19:55, 20 May 2006 (UTC) I did feel some unease at the sweeping removal of the section, but perhaps just because it was interesting. I say scrap it.
  • N.B. http://conlang.wikia.com/wiki/Pi:YHVH_language_page_2#Patterns_and_Antipatterns (apparently by User:Fasten) links here!
  • They are not anti-patterns in a sense analogous to that applied in software engineering: recognised wrong solutions to recognised problems(?). They are more like pitfalls (see the discussion 3 sections earlier) but not really that either, as they are usually not a result of misrecognition. Some of them just grow like that (not design at all), others develop because of selfishness. It is perhaps significant that there is no category for them. If this usage were to apply in sociology it would call for a separate article and a spot of disambiguation.
  • As to POV, I am not quite sure. Calling something an anti-pattern is clearly a value judgement, and EngineerScotty is right that that is controversial in most of these cases. One could say they are "considered to be anti-patterns" – but by whom? – sounds a bit weaselly!.
Agreed. The following anti-patterns lack sources and have been removed from the article. --Fasten 12:32, 8 June 2006 (UTC)

Some social anti-patterns

  • Censorship: Suppressing discussion prevents political, social, and scientific progress
  • Concentrated power: Individuals abuse power, even if initially well-meaning
  • Dictatorship: No individual has all the skills necessary to govern; also power corrupts
  • Discrimination: Discrimination on irrelevant features yields economic inefficiency and social resentment
  • Dogmatic religion: Dogma suppresses individual thought and prevents progress
  • Intolerance: Insisting on changing undesired-but-harmless features of other people causes resentment and is an endless task
  • Monopoly: Without competition most of the effects of a free market don't occur, and a private company has no incentive to do business fairly
  • Plurality voting system: Politics under plurality voting degenerates into two highly-polarised parties, with all other political views suppressed
  • Popularity contest: Popularity becomes a self-reinforcing quality, and is unrelated to any useful measure of merit
  • Segregation: Separate but equal is rarely, if ever, equal; causes resentment
  • Single-party system: Without electoral competition the party has no incentive to govern fairly
  • Totalitarianism: Suppressing individuality causes resentment, and the approved way of life is never even remotely suitable for everyone
  • Victimless crime: Suppressing harmless behaviour creates a subculture of otherwise-law-abiding people for whom the legal system is an enemy
  • Witch hunt: Scapegoats are easy to find, but if the problem is never actually solved then more scapegoats will always be required
  • Year Zero: Social change is an inherently slow process; rushing it yields disaster

"Single head of Knowledge" and "Knight in Shining Armour" are unfounded

PJTraill 20:41, 20 May 2006 (UTC)

I am removing these:
*Single head of knowledge: SHOK applies when a single individual in the entire organization controls vital domain know-how or information on system internals.
*Knight in shining armor: KISA happens when an individual who can do no wrong shows up on the scene and tries to fix everything without communicating
 what changes he/she has/will make and why.
as googling them produced nothing but this article. The formulations are also verbose and nobody has written articles on them since they were added.
SHOK is moreover not an anti-pattern, as it is not usually an intentional solution but arises by accident.
KISA is a bit vague to be an anti-pattern (what problem is it meant to solve?)

Anemic Domain Model

I think Anemic Domain Model should be added to the example list. Martin Fowler wrote about it in his blog here: http://www.martinfowler.com/bliki/AnemicDomainModel.html -- iWat

Did I understand this right? Is Fowler saying that DAOs are an anti-pattern? 83.250.117.164 22:16, 1 January 2007 (UTC)

Thread Hell

I reverted an inclusion of "Thread Hell"; as I cannot find any citations for this antipattern under this name. While I certainly agree that excessive multithreading is an anti-pattern; this article should only reference patterns documented elsewhere in the literature, using the names they are documented as. To do otherwise violates no original research.

If someone can point me to a reference to "thread hell" in the literature, I'll happily endorse putting it back.

--EngineerScotty 19:43, 10 July 2006 (UTC)


Antipatterns are Useful

The assumption that antipatters are bad is not correct. It is subjective. A technique can often be used for good or bad so why not inform the readers. Cut and paste can be useful else it would not exits. Violating encapsulation can be a design decision. Many of the antipatterns are actually great techniques when used in a controlled way. —The preceding unsigned comment was added by 220.240.85.65 (talk • contribs) 15:56, 11 July 2006 (UTC)

Actually this is covered in the book "Anti Patterns" - it describes situations where the 'anti' pattern is useful. Dndn1011 15:12, 14 October 2006 (UTC)

Removed Logical Cube

as it is original research (no mention of this antipattern anywhere in the literature, that I could locate). --EngineerScotty 18:31, 11 July 2006 (UTC)

Warm body up for AFD

The article Warm body, which was referred to here as an anti-pattern, is presently up for AfD. My suspicion is that the article might get saved/renamed/merged somewhere more appropriate; as it stands the article is original research and/or neologism. --EngineerScotty 20:17, 23 October 2006 (UTC)

Expection Handling

While it may have been coined on thedailywtf a few months ago, google searches reveal that it is in use. I'll accept another's judgement if they think it needs more widespread use. If it isn't removed, I'll whip up a short article to link to.124.148.6.57 05:36, 1 November 2006 (UTC)

Singltonitis

Curretly this just points to the singleton article. IMHO singletonitis is a big problem and worthy of an article on it's own. "Singleton considered stupid" ( http://steve.yegge.googlepages.com/singleton-considered-stupid ) is probably one of the better articles on the subject, but theres plenty on Ward's wiki and elsewhere. 217.18.21.2 17:36, 3 November 2006 (UTC)

copy edit

I don't see any copy errors in this article, so I will see about removing the copyedit tag. Puddytang 02:23, 19 January 2007 (UTC)


Bad management?

PJTraill 16:39, 21 January 2007 (UTC) "Managing a project without being sufficiently knowledgeable in the subject"

  1. Is this an anti-pattern? I think not, one doesn't think "It would be a good idea to mange this badly."! But the situation is familiar, so it is at least a pitfall.
  2. Would it belong to SD-project-management or organisation?
  • Here's the text of the item in question.

Bad Management: Managing a project without being sufficiently knowledgeable in the subject

It is just too vague, and assumes tacitly that the role of the manager is to be the knowledgeable one instead of leading the workers who need to be knowledgeable themselves. Does it represent a repeated practice that appears initially to be beneficial in any sense? I took it out. Milkfish 01:30, 6 August 2007 (UTC)

Original research?

Some of the anti-patterns, while interesting, smack of original research (i.e. someone thought them up and added them to the wikipedia page). Notable ones are Batch over MQ (only exists in WP), YAFL (needs a citation), Hero Mode, which I can't find in a google search anywhere else (and may be a symptom of a different anti-pattern), etc. I'm going to leave this comment here a while, and then if no one objects, remove these as the list is starting to have list-itis. -- Metahacker 20:13, 22 February 2007 (UTC)

How is this an Anti-pattern?

When I look at your definition of Anti-Pattern, I feel that some anti-patterns don't belong here, or aren't anti-patterns at all. Your definition is: commonly-reinvented bad solutions to problems.

Bad managament: doesn't feel like an anti-pattern because it's too general. The definition almost makes sense to me, though.

Circle-Ellipse: Is this really an antipattern? It looks more like a problem with the design of most programming languages.

Silver Bullet: The link has nothing to do with computer science. In addition, I can't see the difference between Golden Hammer and Silver Bullet. I'd be tempted to say that Silver Bullet actually means "right tool for the job", which is the antonym of Golden Hammer and not an antipattern at all. Could someone be more precise on the meaning of Silver Bullet?

Configuration management antipatterns: I don't see how any of these belong to a discussion about anti-patterns. This talks about software deployment, not software design.

Stovepipe: has a red link. It should probably point to Stovepipe system or to Stovepipe (Organisation).

Magic strings links nowhere (there's a typo in there, by the way), and looks a lot like hard coding. If not, a stub with a couple examples would be great. Do you mean something like if ( obj.GetType() == "System.String" ) instead of if ( obj is string )

In addition, Category:Anti-patterns and this page are out of synch. For instance, where one says Race Condition, the other says Race Hazard (this last one seems more correct). Busy Spin vs Busy Waiting. Hard code vs Hard coding. Magic number (programming)#Magic numbers in code vs Magic number (programming).

Premature optimization doesn't appear in the Category page. Dll Hell is in the Category Page, but Jar Hell isn't? Cash cow, Management by perkele, Scope creep don't appear in the Category page.

Code Smell is in the category page as an antipattern, but here it's in the See Also section?

(I didn't list articles in the category which are not in the main article because you state at the beggining that the category page is a more exhaustive list)

Ruijoel 11:01, 12 March 2007 (UTC)

  • Circle-Ellipse is not in and of itself an anti-pattern, but it definately demonstrates a very important class of problems and should probably be at least mentioned. (I found that link particularly useful.)
  • Much like Circle-Ellipse I, for one, would prefer Code Smell was simply mentioned in text (preferably) or See Also
  • Golden Hammer appears to me to be junk. Silver bullet, however, is an established term. I think Fred Brooks jr. in "The mythical man month" noted that "there is no silver bullet"; i.e. that some complex things are complex by necessity and there's no simple trick to make it go away. I can't say whether or not this is an anti-pattern, but the term is known.
  • Also, I earlier edited Managerial Cloning to note that this is known in sociology as "Homosocial reproduction", but the edit was rejected. (I can't say whether or not this is an anti-pattern either.)

C96aes 23:14, 29 June 2007 (UTC)

The reason some things (e.g. Premature optimization) are not in the category is that they link to sections, which cannot (as I understand it) be category-tagged. I also agree with C96aes that the page is more useful if it includes pitfalls as well as anti-patterns. The borderline may be fluid, and they are easier to find when they are in one place. I think putting pitfalls under "See also" is less helpful. On the other hand, the page does need regular maintenance to keep out junk. Ruijoel also seems to miss the point when they keep talking about "you". PJTraill (talk) 01:22, 27 January 2008 (UTC)

As a software manager i'm often referring my co-workers to some blue links here, the most common anti-patterns, the ones with a real description.

There have been so many added over the time, and so few with something argumented behind. Doesn't it sound like this page itself falls in the Smoke_and_mirrors anti-pattern?

I'm also skeptic about some of these, because they go too far on the four-words-say-it-all tagline-style naming, especially when much irony and winks are involved (and this --- is not an anti-pattern but False_analogy fallacy). This could lead to oversimplification, and some cultures are not receptive to irony --- at all.

By the way that's my first comment ever on a wikipedia article, and english is not my first language (french guy) so please be indulgent on these topics.

Thanks for reading,

68.125.166.248 03:48, 8 April 2007 (UTC)

Merge Code smell?

Code smell is a name for a subclass of this concept (see [4] for a discussion of smells being antipatterns), presumably having been independently invented by the XP crowd. Should that article be merged here? JulesH 09:00, 15 June 2007 (UTC)

"Hebrew-bricking"

Edit at 2007-11-18T01:12:21 by 207.11.79.52 removed "Hebrew-bricking", added in edit at 2007-11-10T08:08:08 by 76.2.24.11, calling it "made up and bigoted crap". While I've never heard this term used and cannot speak to its being made-up, it is not bigoted or otherwise anti-semitic; it is a reference to the Biblical story of Pharoah forcing the captive Hebrews to manufacture bricks without adequate materials. I don't support its re-addition because it, like most of the nonsense on the page, is not a real design anti-pattern but just a cutesy term for a stupid thing that tech managers do, but I wanted to set the record straight about the "bigoted" part. Chaos5023 (talk) 22:37, 18 November 2007 (UTC)

Programming by accident

I found the previous description of programming by accident as:

  • Programming by accident (or debugging by accident): Resolving program bugs by blindly 'correcting' items, like removing white space or rearranging lines. Instead of spending time researching root causes of bugs, time is wasted trying to fix things blindly.

not only too wordy but also rather unlikely: people may fiddle with the layout to make the program easier to read, and hence understand it better, but surely not in the hope that it will suddenly start working! I therefore googled, which yielded more or less what I had expected. What I did not find what "debugging by accident" (except this: http://www.west-wind.com/WebLog/posts/681.aspx, which is curious but something else). I accordingly replaced the above with the following:

  • Programming by accident: Solving problems by trial and error, usually because of a lack of documentation or not taking time to think things out.

To be honest, I think it is more of a pitfall than an anti-pattern. In order to keep it short, I have omitted a number of points, which seem too much for a one-liner and too little for an article:

  • may be a good approach to learning, more likely to remember what you try out and test
  • not likely to work if you are not on the same wavelength as the designers of what you are using
  • may refer to other unstructured approaches
  • may be a reverse-engineering approach, looking for undocumented features
  • excessive chance of producing a solution which happens to work in your development environment but fail disastrously elsewhere

PJTraill (talk) 22:30, 14 February 2008 (UTC)

Descriptions on "See also" are useful

I see that User:Bankbryan/User_talk:Bankbryan removed in http://en.wikipedia.org/w/index.php?title=Anti-pattern&curid=233956&diff=191032030&oldid=188767622 the descriptions I had added to the links under "See also". I wonder why: surely it is useful to give people an idea what they will find there (especially for "Code smell"), to save the trouble of following links they are not interested in. I am putting them back, perhaps anyone who wants to remove them could present their reasons here, and see what others think before doing so. PJTraill (talk) 23:41, 14 February 2008 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Anti-pattern/Archive_1&oldid=1248647148"