It Fad Smell

Information Technology Fad Smells (warning signs)

• They take a few catchy-sounding concepts and exaggerate them to full throttle (MoreIsBetterFallacy)
• Every major book vendor suddenly has a related title
• Most evidence is anecdotal
• The people pushing them are known to have been involved in past fads that fizzled
• They say, "Skeptics, YouJustDontGetIt"
• It becomes popular at a faster rate than good research or road-testing is being produced on it. There is NoShortcutForRoadTesting.
• Existing projects are too small to serve as good test cases such that scaling is under-tested.
• Demonstrations of its ability are based on somewhat artificial, over-simplistic, or "toy" examples (ArgumentByLabToy).
• Difficult to find or contact actual users to get fuller, unbiased feedback.
• Hints of falling victim to the EightyTwentyRule - it indeed simplifies some stuff but is fuzzy on how it deals with the details of fine-tuning and customization. (Per above, demonstrations and justifications may just emphasize the 80%, downplaying the rest.)
• Fear-mongering - "If you don't use it, bad things will happen. Data will become corrupt; programs will run out of RAM; misplaced brackets will kill kittens, etc."
• GoodMetricsProduceNumbers, and round-about "logic" with lots of steps and possibly hidden assumptions are an insufficient substitute.
• Always do X or always use X - Non-trivial technology design involves myriads of tradeoffs and exceptions to the rules. "Always" is a smelly, zealot-suggestive claim.
• The entirety fallacy: if it's good for a few cases, then it's good everywhere such that one concept should run the entire show. (This differs a bit from the 80/20 rule above in that one may still use the tool for everything, but the 20% may drag down its effectiveness. In other words, there's the benefits of the tool/technology for doing the entire project versus using it for parts.)
• If it doesn't work, they'll say, "you haven't used it long enough. It takes a while for the benefits to kick in."
• If after several years, it still doesn't work, they'll then say, "Well, you need to hire expert consultants to tell you how to do it right, us, at $200/hr".

And now the interesting part: identify, let's say, three tools or techniques developed during that last thirty years that are today considered a valuable part of the mainstream but which, at their first introduction to the industry did not have the characteristics of a fad mentioned above. For bonus points, explain how to discriminate which current "fads" will, and which will not, enter the mainstream some years from now.

I'll suggest a categorization here:

Were generally accepted with relatively little resistance:

• StructuredProgramming (code blocks instead of goto's)
• GUI's
• RelationalDatabases (it could be argued that OODMBS and XML later challenged this to some degree).

Generally faded into narrow niches:

• ExpertSystems
• CASE tools
• Extreme top-down procedural programming (roughly late 70's)

Remain, but created HolyWar camps (note that cults, with the death of their founder, routinely fission into two holier-than-thou camps):

• ObjectOrientedProgramming (Note 1)
• FunctionalProgramming
• ExtremeProgramming

Too early to call:

• XML (ExtensibleMarkupLanguage) (Note 2)
• Web-based apps
• RecordBasedDatabase
• WebServices
• ServiceOrientedArchitecture
• CloudComputing

---

Pattern of Claims

• End-users can write/generate/specify their own programs, reports, queries, etc. via an easy-to-use interface with little or no training (ComputerProgrammingForEverybody)

• Reduces redundancy in code

• Increases code-reuse

• Makes the code shorter

• Makes the code easier to understand

• GUI or visual-orientation makes programming quicker or "more natural".

• Code pattern analyzer or pre-compiler catches all your mistakes

• The organizational process or methodology reduces having to think

• Makes the computer do all the work so you don't have to

Note that incremental gains in each of the above may be possible, but rarely is it a leap. Even the grand ideas that have proved useful still took a while to mature.

Unless your organization wants drama or makes an income researching new ideas, let somebody else be the Guinea pig.

---

Web-based Application Argument of Questionable Usefulness:

Web-based applications are successful for many low-complexity applications, but still struggling at the higher end.

Please define "successful", "low-complexity", and "higher end". Otherwise, your comment is meaningless; it can be applied to almost anything.

That's a tall order, but successful examples would be on-line personal banking and bill-paying, web-based email (for personal email), and 2D Flash games.

I presume that is definition-by-example (dubious at best, worthless on average) for "successful" and "low-complexity". How do you demonstrate that web-based apps are "still struggling at the higher end"? On second thought, don't bother answering. I'm sure this will turn into the usual debate black hole that sucks in time and effort and emits nothing.

Tell you what, send me $10 million and I'll send back a double-blind certified peer-reviewed study.

So... It was just a random comment based on your supposition and limited knowledge, then?

Yip, just us little mortals.

This threadlet could be removed and no content would be lost. Agreed?

Hold on, Tex, which parts of this wiki require double-blind certified peer-reviewed studies and which don't? If we are going to draw a deletion threshold line in the EvidenceTotemPole, let's make sure there's a wiki consensus rather than just apply it arbitrarily to the people you hate.

You'd probably like to be hated, but you're unimportant and therefore unworthy of hate. My problem with this is that it's clear your comment was simply random. You didn't have any knowledge or experience to offer, it was simply a throw-away opinion-based comment, a keyboardwise flapping of the jaw, like "Fords are better than Chevies" or "the Redskins will win this year."

It is based on my experience as a consumer and IT professional. If you are going to card me then card every wiki contributor, otherwise you will look like a biased vengeful pompous dickhead.

It's based on your unqualified "experience" as a consumer and IT professional. In other words, you offered your casual perception. I.e., you offered no more knowledge than that possessed by any other run-of-the-mill consumer, or an IT professional who has little or nothing to do with "high end" Web applications or even Web development in particular. In short, you don't know what you're talking about but that didn't stop you from commenting, and you know it.

If it jives with others' experience, it tends to stay as is; and if not, it's modified or commented on. This wiki serves as a sort of an organic aggregater that way. Each "voter" pushes the wind vane slightly until it comes to a consensus orientation. Yes, it's not perfect, but that doesn't make it useless. (I think there's an AI term for a "device" that "collects" experience by having each training instance "push" it slightly based on feedback.)

---

Three tools that did not are e-mail, spreadsheets, and instant messaging. None of them (except IM) had much marketing, and they mostly flew in under the radar of the experts. IM was not marketed to programmers, but has turned out to be an important tool for those working in distributed groups. E-mail might predate 73, though the other two didn't.

But you have a good point. -- RalphJohnson

---

Unlike other things that smell, these might not all be all bad. Some provide pleasant pastimes. See AcronymBingo?.

---

Related topics? EducationalReformFadSmell?. In fact there may be a whole slew of these in business and politics (HealthCareReformFadSmell?, BetterManagementFadSmell? etc.). This may be an instance of a more abstract AntiPattern -pjl

---

Notes:

1. This has got to be somebody's idea of a joke. OOD and OOP are essential tools in creating modern products. Add functional programming to that as well.
   • I'd say that OO has become a common tool as part of a larger tool kit. The controversial aspect is "pure" OO versus it being a portion of an app. -t
2. XML is an accepted transport used throughout the world for all kinds of data packaging. There is no question about XML being an accepted technology that is here to stay. For instance, XML shows up in the index as mentioned on more than 1300 pages on this wiki.

RE 1: One must wonder how "essential" the OOD/OOP tools actually are. Whether they are a 'fad' really depends upon whether they will prove to be essential tools in creating modern products twenty years and forty years from now. I suspect not, though I'll bet the tenets of ObjectCapabilityModel and capability based designs will grow more relevant (and be translated into many other paradigms).

RE 2: At one point COBOL ruled the world. Just because XML has been accepted for now does not mean that it will remain popular in the future. There are plenty of competitors today and on into the future (YAML, JSON, Argot (XPL/TRP)). The horse I'm betting on involves focus on APIs and code-distribution: after some interaction you provide me various capabilities to your system, and I may either interact with them remotely or I may send you a block of code to manipulate your caps on my behalf. You decide just how expressive an API you want to provide; APIs can readily be documented and standardized. (It isn't as though we've ever successfully avoided reinventing scripting languages inside HTML or SQL systems or XML or anything else. We always reinvent them.) Ideally, the language will make a variety of useful safety guarantees... i.e. regarding termination, concurrency, failure modes.

---

See: NextBigThing, CarlSagansBaloneyDetectionKit, MagicLegos

CategoryFuture, CategoryEvidence