AntiPatterns
From Ohmpedia
This page is severely under construction!
Description of commonly encountered problems in software. Currently this page covers everything; maybe split later...
Contents |
General
Breaking multitasking
General idea of this. Related to more specific examples, like Pretender to the Throne, Hells and Whistles.
Hells and whistles
Potentially intrusive extras (e.g. music for a game installer) that break multitasking and are not optional.
Re-invent the wheel
Obvious one, but it still happens. E.g. someone at my company wasted time making a bug tracking system. I asked them, after the fact, why they didn't just use Bugzilla. They sheepishly replied that they didn't know it existed. Two approaches to avoid this:
- google for what you need! someone might already have done it (obvious)
- make a habit of keeping tabs on current software out there anyway, particularly free/open source! (e.g. bugzilla)
GUI
Invasion of the widget snatchers
Widgets that behave in non-standard ways or appear in the wrong place. (e.g. see that X in wrong place in symantec scan history box... add illustration)
Resource misuse
Pinhole view
Dead GUIs don't talk / Threads, shmeads...
Nagging / Poor automation
Stranger in the street
Communications that lack context! (Also, an annoying variant: modal dialogs popping up that demand info but don't allow window underneath to be seen, e.g. it is still minimused. The classic: windows notepad, when you shut down windows....)
Pretender to the throne
Describes apps that take a sovereign posture when it is pretty needless. (Typically, game installers do this.)
See also "Breaking multitasking."
Language use
Use the letter of the language, but not the spirit / Square peg, round hole
e.g. making java look like perl!
Source code distractions
Sometimes in form of political/stupid comments. Increases cognitive load of someone editing code, distracts. Plus, how do you know who will read that source code in the future? could be embarrasing. The most typical one: writing comments about "M$" etc.
OO
Inheritence is usually not for re-use
Inheritence is for specialization. That may then lead to re-use...
A common inheritence misuse is using inheritence when really the code should be using (delegating) to another object (as in x "uses" y (aggregation), or x "has a" y (composition)).
If x extends y, and x is never used in a context of being type 'y', this is usually a good indicator for checking you're not abusing inheritence.
More fluff to be classified
management: loose liability
management: money talks, standards and quality walks (important or rich client involved in a project. Management expect you to deal with unprofessionalism and slackness from external parties, because they don't want to lose them.)
automation: pause on information
GUI: manager as designer?
Primary author: Alex Hunsley
