The best teacher I ever had was an ostentatious man. He taught tenth grade history and geography at my high school. He would regularly show up in full costume for presentations about the Roman Empire, the World Wars, and other major events in our planet’s history. He was vivacious, funny, a man who knew his subject and loved to teach it. I can vividly recall his “death tests” about geography and countries, and how my classmates and I spent an inordinate of time studying for them. He was tough, yes, but he was fun.
Bikeshedding occurs when a development team spends a disproportionate amount of time and effort on a trivial or unimportant detail of a system, such as the color of a bikeshed. This most often occurs because the supposed “trivial” detail is one of the few such things that everyone in the room actually understands.
The solution is relatively simple, but scary: someone needs to be a dictator. Or, in our particular case, an admiral.
The Rundown
- Name: Bikeshedding
- AKA: Law of Triviality
- Summary: Spending disproportionate time on items with insignificant impact or little importance.
- Type: Management AND Methodological
- Common?: Can’t we all just…
The Golden Hammer is a methodological software anti-pattern in which a team which is very familiar with a particular tool or methodology uses that tool or methodology as a solution to every problem they encounter. It originates from a popular phrase: “If all you have is a hammer, everything looks like a nail.”
So what’s the solution? Get a different tool. Why use a hammer when all you need is a timer?
The Rundown
- Name: Golden Hammer
- AKA: Law of the Instrument, Maslow’s Hammer
- Summary: Occurs when a team or individual decides that a particular tool with which they are familiar is…
A Boat Anchor is a programming anti-pattern that occurs when a part of a system is kept in that system despite it no longer having any use. Generally this is because of developer belief (or prior experience) that they’ll need it later. This belief is almost always wrong.
The solution is precisely what you think it is…
A Big Ball of Mud is a software design anti-pattern in which a software system lacks a perceivable structure. This means that, to an outside observer, the system has no discernable architecture, and as such, looks thrown-together, haphazard, and is a massive pain to maintain.
Big balls of mud are extremely common in our industry. So what do we do about them?
We architect. Otherwise, we’re gonna need a firehose.
The Rundown
- Name: Big Ball of Mud
- Summary: Code in a system which lacks a perceivable architecture.
- Type: Software Design
- Common?: …Are you sure that’s mud?
Give Me an Example!
Straight from the horse’s mouth, as…
Cargo Cult Programming is a methodological anti-pattern in which developers include code in a system, but do not know or understand the reasoning why that code needs to be included; they only know that by including said code, the program works as intended.
The term originates from actual cargo cults, undeveloped South Pacific civilizations which saw people like the dude with the orange sticks below guiding airplanes with cargo (including food and clothes) onto their island, and assumed that it was the sticks themselves that summoned the airplanes, rather than the airplanes needing the person with the sticks (as you…
Death by Planning is a management anti-pattern that occurs when a project is planned so thoroughly that the development team runs out of time to actually build it.
The problem is that the teams involved in this anti-pattern believe they need to know everything before than can start building. This is, of course, impossible. So what do should we do instead?
We should just build the damn thing.
The Rundown
- Name: Death by Planning
- AKA: Detailitis
- Summary: Occurs when a team attempts to plan out a project so thoroughly that they run out of time to actually build the project.
- Type: Management
- …
A God Object in software development occurs when a single class (or other item) either knows too much or does too much (or, for extra fun, both).
The solution to this anti-pattern is fairly straightforward and rather ironic: smite the God object.
Although you may prefer the term “refactor”.
The Rundown
- Name: God Object
- Summary: A class or other object knows too much or does too much, and is therefore difficult to test or change.
- Type: Programming
- Common?: Omnipresent.
An Example
Let’s say you are building an employee management application (yes I know, very original). Let’s also say that you have the following class:
…A Stovepipe Enterprise is a management anti-pattern that happens when different groups in a single company are responsible for designing their own systems from the ground up, completely independently of the other groups, and with no cross-group direction. What results is that each team has their own environment, standards, architecture, and data sources and none of the groups can work effectively with one another’s systems.
What you end up with is similar to a pipe organ: lots of individual pipes, none interacting with one another, each only able to produce a single sound. …
Lava Flow is a programming anti-pattern that occurs when code which works, but isn’t well documented or understood by its maintainers, is kept in a system because it works. In other words, lava flow is any code which is kept around because no one has the time or willingness to understand it, or indeed, even go near it. Such code can be said to “flow” through the system it inhabits.
The fix for this anti-pattern depends heavily on whether the lava flow has already occurred. My team is directly dealing with this anti-pattern as we speak, even deliberately causing it…
