Golden Hammer

Definition: The belief that there is a technology or tool that significantly improves productivity, reduces errors, shortens code, etc. without significant drawbacks.

AntiPattern Name: Golden Hammer

Type: Development

Problem: You need to choose technologies for your development, and you are of the belief that you must choose exactly one technology to dominate the architecture.

Context: You need to develop some new system or piece of software that doesn't fit very well the technology that the development team are familiar with.

Forces: Supposed Solution: Use the familiar technology anyway. The technology (or concept) is applied obsessively to many problems, including where it is clearly inappropriate.

Refactored Solution: Expanding the knowledge of developers through education, training, and book study groups exposes developers to new solutions.

Compare: SilverBullet.

Examples:

I object to calling it "anti-pattern" this early in the page. Although I generally don't believe in person-neutral GoldenHammers, I believe it unfair to criticise it as if it is a consensus fact that there are no such things. About two-thirds of those I debate on this wiki seem to believe golden-hammers exist. (I don't claim them representative, however.) --top

Really? As mainly an observer in your debates, it seems to be somewhat the opposite. Though admittedly not as prevalent these days, I seem to recall someone peddling TableOrientedProgramming as at least a chrome-plated hammer, if not a GoldenHammer. This Wiki is generally refreshingly free of GoldenHammer thinking, at least in comparison to the many less-considered sources that would have us believe (as of July 2008) that ServiceOrientedArchitecture or Mashups are the solution to all IT ills.

I only peddle it as a valid alternative or supplement: one choice among multiple. I don't claim it should summarily replace everything. This differs from the "absolutionists" who insist their GoldenHammer should replace existing stuff. (In the old days I was more insistent, before my "psychology-matters" epiphany.) --top

BrowserConstrainedApplication doesn't seems like an example because it is not a result any one of the above mentioned forces, but due to the need for universal access. -- OliverChung

I have worked on a number of applications that had no actual need to be browser-based (internal company applications) and would have been much easier to implement as a thick client application. A BrowserConstrainedApplication? is the first thing I think of when someone talks about a GoldenHammer -- BrianDeacon

Building for universal access and building for the browser are very different things. Using "web technology" as the GoldenHammer very often leads to intractable, single-use, BrowserConstrainedApplications. I have been guilty of this anti-pattern in the past, but am reformed. -- JimArnold

What other such universal access architectures (preferrably with a interoperable standard and multi-vendor support) are there, where you can connect from cybercafe, PDA, cellphones, laptops, etc almost anywhere in the world today, other than HTTP/HTML? -- OliverChung

I don't think that's the point. In the context of GoldenHammer's, a team with whose skills are, primarily, in web development are likely to build an application which precludes the use of other clients. Sure, you can build just about anything with ASP, but try accessing it with anything other than a browser. What about the people who don't need access via the internet? -- JimArnold

Well, the page linked above describe BrowserConstrainedApplications's problem as "Sales people need to access FOO on the road, possibly from a CyberCafe, at home, and in the office.... the application needs to be accessible everywhere on the network, with uncertain client-side support". So the system requires universal access with uncertain client-side support. If HTTP/HTML is the only solution, how can it be blamed for the constraint imposed by the browser? What's more, the "Applicable Positive Patterns" section in the above linked page doesn't even address the basic problem, because "creating multiple clients" is not going to allow access from CyberCafe, unless one of them is HTTP/HTML. There may be cases where using HTTP/HTML is due to GoldenHammer's forces, but the BrowserConstrainedApplications is not one of them. -- OliverChung
Development AntiPattern prominently featured in the AntiPatternsBook. (http://www.antipatterns.com/dev_cat.htm) Someone has to bring that into shape: AntiPatternTemplate
I can't tell you how many times I have landed in gigs where the client's "engineering" staff was still designing stuff using 80186, Z80, or -- this makes me gag -- MCS-51 family technology. Can't the 8051 be allowed to die a natural death?!? Fortunately, I have priced myself out of most of the work that these loozers represent. However, the kind of thinking that has engineers designing 21st Century products using 1970's steam-engine technology still persists. I run into people designing state of the art electronics hardware and trying to shoehorn UNIX into the box because that's all they know. Duh! Duh! I was thinking about offering a sort of anti-Dilbertism service on my web site. You know the routine; "Have me come in and slap your engineers around a little until they Get It®."

You can't have it both ways, dude. Sounds like you're trying to shoehorn in 21st century uber-processors into a steam engine. Sometimes a hammer actually is the right tool. So is an 8051.

No, I am not trying to use more processing horsepower than is called for by the application. I am trying to avoid the continuous use of 30 year old technology just because the client's engineering staff stop learning anything that long ago. This is not hyperbole; this actually happens, even today. It shocks me into stunned silence to see the kind of crap I wouldn't use to operate my toaster being crammed into medical diagnostics and industrial process automation. Holy moley.

... and it worked just fine for another 20 years ...

I have found myself implementing simple already-solved solutions that would work just fine, thank you, if done with an 8-bit micro, but since "this is the 90s" or "it's the 21st century" we "must use the latest stuff" to build a gadget that turns a light on, rings a bell, reports tilt conditions of remote devices to a central location. So we move from a $30 part to a $300 part, hire some guys who are a little fuzzy on what a TeeState is, and off we go. OMG. It's a WheelFactory. But, we SparedNoExpense.

Okay, try this on for size: I recall one client who made industrial temperature controls for various industries. In the case of metal heat treating the response time of the system could be measured in minutes; in the case of certain plastic molding machines the critical temperature cycle could be measured in milliseconds. These guys were developing temperature controls with all sorts of real time features, nifty user interface, and networking -- using a blankety-blank 8051! The only way they could get their junk to meet latency specs was by going to an even faster 8051 variant made by Dallas or somebody. (Dallas had a version that ran at something like 60MHz, whereas the original Intel device topped out at 2.) Some of their later designs had two or three 8051s in them to spread the work load around enough so that the junkbox microcontrollers could handle it.

Had these guys switched over to something even as recent as a 68HC16 (1980's technology) they could have met their real time constraints, had all the processing power they could shake a stick at, and eventually created a less expensive, less complex, and more reliable piece of hardware. But, nooooo! They had to stick with the craprod they knew. Oy! What a pile.

Sometimes there are good reasons for NotInventedHere and sticking to known methods, even if there are "better" ways of working. idSoftware had problems releasing Doom (correct me if I'm wrong) because they used a proprietary sound library without redistribution rights. Sometimes throwing a 100Mhz 6502 at a problem that a 6502 can handle is easiest - software can be fiendishly complex, keeping a working design but clocking it faster might save a lot of money, despite the overall sillyness of 100Mhz 6502s. The trick is to realize when your golden hammer is requiring more work to support than you save by using it. In the case of three linked CPUs (wow, the concurrency issues!) you're probably better using one faster CPU. How can you tell? Unfortunately, without experience you aren't aware that not only aren't you using the best tool, but often you're unaware that there are other tools.

The opposite problem is that new tools which solve a fiendish old problem have the tendency to appear magical.

It's a good reason to keep your design modular. You can swap out a home-written macro parser for an off-the-shelf LISP interpreter, or write a module in perl to take advantage of the ManagedCode and RegularExpression capability, or call a C program from Perl for something that demands ASM-like control.

Probably the best lesson here though is to expose yourself to new things. PairProgramming is a micro form of this - hiring interns and swapping programmers between projects is a macro form of this. If you aren't afraid to RefactorMercilessly and you can write the same code in a few ways, or port your code to a new platform, and experiment. It's a good reason to avoid tying yourself to any technology you don't have access to - OpenSource is freedom.

Open Source is a wonderful thing and doesn't help you at all when you are trying to create a tightly enclosed, microcontroller-based electronics package. As far as determining when it is best to drop the use of a handful of Old Fart processors and go with one New Kid On The Block processor, well, that's what spec sheets and sales engineers are all about.

My contention is that the clients who insist on using Bronze Age technology are the same ones who don't want to do any research on what's out there now. These are the companies that are going to be eaten alive by their competition. I like to rub their noses in it every chance I get. Some of them Get It®. Others don't. The ones that understand alter course and typically survive to make new, better products. The ones that don't want to make waves end up sinking.

Such is life. And death.
IfItsNewItMustBeBetter -- My toaster works fine without 21st century refinements, I just put the bread into the toaster, push the lever down, and the toast pops up when done. This is all I want from my toaster. I usually add some butter or jam using an old-fashioned table knife. -- SimpleSolutionsForSimpleProblems

My toaster has one refinement I enjoy, a little lever which pushes out bread that's either too short to spring out or has failed to spring for some reason. I'm also enjoying the ones made with wider slots for thick bread or bagels. Not sure if those are 21st century refinements or if I've just had low quality toasters before.

The features you describe are 20th century. In addition, many toasters have a slider control which controls the lightness/darkness of the toast. Perhaps the earliest versions with sides that drop down could be adapted so that the drop down would be at the time pop-up toasters usually pop-up. I can visualize them springing open, with the toast ready to buttered or jammed. They could have space that was wide enough and spring adjusted to hold a half-bagel on each side. (Sunbeam, are you listening?)

I rather like the fact that my fancy-dancy new toaster is on a timer and not a thermostat, so when my girlfriend's toasting her bagel, i put mine in and the lever doesn't immediately pop back up in a few seconds, like it always did with the old fashioned one. The lever activates the digital timer and is still on a spring (but it's released with a digital "cancel" button on top). I'll be the first to say that motorized toasters that slowly lower and raise the toasted product are just ludicrous. I am however annoyed at my coffeemaker which only has logic buttons for on and off. It has no timer built in, and I can't even put it on an external plug timer because of the full logic controls. Means I can't wake up to hot coffee. I'm starting to think of an automatic button-pusher on a solenoid activated by an X10 sensor, but she's not a fan of my grungy hack tech on our appliances...
Personal GoldenHammer

People are different and some technologies may fit the way an individual thinks more than others. While there may not be any global GH's, it is possible that there are individual GH's. If PaulGraham says that Lisp makes him super-productive, I have little reason not to believe him. --top

See WhyWeNeedSpecialists
Nice phrase: LinguaSalvatorEst - "the language is the saviour" (roughly).
There are no golden hammers ... but there are a lot of people out there trying to pound nails in using:

Convincing these folks to use a steel hammer is quite difficult.
See: HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence, HolyWar

CategoryAntiPattern, CategoryEvidence
EditText of this page (last edited August 1, 2008)
FindPage by searching (or browse LikePages or take a VisualTour)