Kill Two Birds With One Stone

AntiPattern Name: Killing 2 Birds with 1 Stone

Also Known As: Feeding Two Birds with one Seed (why would anyone want to kill a bird, much less two birds??)

Most Frequent Scale: Application

Type: Development Architectural Management

Root Causes: Sloth

Unbalanced Forces: ?

Problem: Management makes long term decisions on SwissArmyKnife software without discussion with original architect.

Example(s): just about every software package that I have written

Anecdotal Evidence: 'Its got to be cheaper'...

Refactored Solution: Architects should be less concerned with generic reuse and create and design applications that satisfy specific requirements. Let the underlying framework or language be the route to cross domain applicability.

Resulting Context: ?

Applicability to Other Viewpoints and Scales: SwissArmyKnife

[Author: James Fuller (jim.fuller@ruminate.co.uk) / www.ruminate.co.uk]

-- 213.122.9.244 (moved here from page with similar name created on Jan 5 2004)

Did you ever try to kill even one bird with a stone? It's hard enough. Don't try to kill two. -- RonJeffries

Hmmm... this pattern may fly in the face of a do one thing at a time with a line of code type of thing. The idea is that something that can usefully perform two functions should since it is less costly and more elegant. An simple example is to combine heat conduction and rf shielding in an instrument. But getting multiple functions from the same structures you save money, make the product lighter than it would otherwise be, etc. This can be extraordinarily important in weight critical applications. Since software is weightless (sort of) it may not be entirely applicable there. -- RaySchneider

This seems to share some common thought turf with ForFree -- GarryHamilton

Nature also uses tries to solve multiple problems with a single solution. Example - blood carries nutrients, oxygen as well as providing clotting functions for wounds. Lungs extract oxygen, expel carbon dioxide and provide airflow for speech.

True, but it takes millions of years and the death of countless unfit individuals. And some of the designs are brain-dead, like portions of the human airway being used for food.

: Why? Perhaps there's some benefit to having one and only one manner of bringing in largish quantities of matter. Then there's the matter of maintaining the similarity between smell and taste-smell ("hmm... that rotten odour got much stronger when I put that moldy bread in my mouth... spit it out sounds good"), to say nothing of the ability to spit out food and drink when its unfit nature is detected late in the munching stage. All that can be achieved without involving the airway (or at least, only involving the part between the back of the mouth and the nose). It's the position of the larynx that causes the problem; great - we get vocal chords and we get to talk but we also get to choke.
: "clotting functions" are not a solution to a prexisting problem, but a solution to a problem caused by having blood.

In a business environment, CodeDoesNotGetReused?. It just doesn't. Firstly, the technology changes too quick (hands up everyone who will be using Java 1.4 code when 1.5 comes out). Secondly, reuse requires proper documentation and support. In RealLife, code reuse (in JavaLanguage) happens by way of OpenSource libraries. Anything you make that's general enough to be reused will already be out there on the net.

Reuse, in the current immature language/tool/db environment, is a total myth. Part of it is that by extending one slightly overlapping domain into another, you now have more 'space' in which testing, redesigning, refactoring, redocumenting and other work is needed. Even with 50% overlap of 2 regions, you now have 150% to fix instead of 100%.

CategoryAntiPattern CategoryIdiom CategoryArchitectureAntiPattern