原创 2003年10月09日 17:05:00


Software Fashion

By Robin Sharp, Dino Fancellu and Matt Stephens
October 5, 2003

Related Articles: The Case Against Extreme Programming, EJB's 101 Damnations

Britney's let herself goLike any industry, the software world suffers its own fashions. We often see new technology bound onto the software stage with a great fanfare. "Everybody's talking about it! Digital Code Scrubbing is the future! All code should be scrubbed!" Then, after a year or two, the new technology quietly skulks away into the fashion graveyard, when people begin to realise that the technology just hadn't delivered on its many inflated promises (as demonstrated by Britney, our sexy young model over on the left).

At worst, the technology will die out. At best, the fab technology will find its correct niche - the niche that it should have comfortably filled in the first place.

In the "real" fashion world, bell-bottoms, miniskirts, hotpants, Farrah Fawcett hairdos, Calvin Klein pants, fatness and thinness have all come and gone as either the thing to wear, or the thing to be. We tend to look back on fashions past with either fond nostalgia or a twinge of embarrassment. In the software world, it's not that different.

A good example of an over-hyped technology dying out is WAP. The initial hype suggested to both punters and content providers that WAP would provide "the Internet on your mobile phone". The reality, of course, was like playing tennis in a broom cupboard: a rather pathetic text-only display dribbling onto drooling punters' tiny-screened phones. The truth was considerably different from the promises bubbled out by marketing hypesters and IT journalists regurtitating inflated press releases about WAP's joyous [money-making] potential.

Hype and overselling is a big contributor toward software fashion. Hype is usually at the executive level - describing technology to managers. To do this, the hype must be distilled down to its core, generic essence . . . which is:

Technology X = Money/Success/Silver Bullet

Greed is also a driver behind certain types of fashion - but in the IT world, it's surprisingly a niche player. It seemed most prominent with WAP: content providers thought they were going to make megabuckets of cash from this new age of mobile computing.


Inappropriate Use of Technology

Software fashion means "everybody's doing it!" - which in turn means "you're mad if you're not doing it too." A direct consequence (which can also recursively feed back into the hype and overselling) is the inappropriate use of a new product or technology: like using Black & Decker's amazing new UltraHammer to fit a light bulb, or like a fat girl in a crop top.

In the software world, some examples of inappropriate usage are: EJB for a small ecommerce app; extreme programming for a short-term project with stable requirements; Struts for a web project where plain old JSP + JavaBeans would do the job handsomely; taglibs where adding a new meta-language rewards the team with nothing but confusion; or Model 2, design pattern mania where someone on the team has read GOF and hence decided to shoehorn as many design patterns as possible into their design.

Design pattern usage is often seen as an end in itself. Robin (intrepid co-author of this article) was once asked during a job interview: "What's your favourite design pattern?" What's the correct response to that? "Oh, Decorator every time! Yeah, I use it for everything!"

Web services technology also gets more than its fair share of misuse. Web services are great, if that's really what you need. The problem arises when people use web services "just because", or apply web services inappropriately, like using SOAP as an internal messaging bus.

When hype overtakes a person's ability to appraise a technology objectively, then of course it's going to start to be used for the wrong things.

Micro-Horse Unleashed
Micro-Horse Unleashed

XML has suffered a similar mass misuse. As with web services, programmers use XML "just because".

For example, XML increasingly gets used as a language, via taglibs or (flinch) XSLT. XML is best at representing data in a clean and open fashion. Anything more is stretching the point, like sticking a saddle on a pig and calling it a micro-horse. Inevitably, books then start to appear that rationalize the industry's madness, such as Micro-Horse Revealed, Micro-Horse Developer's Guide, or Teach Your Micro-Horse to Sing in 21 Days!

Is this industry-wide insanity down to mass hypnosis? A general tendency for otherwise sane and rational people to apply some bandwagon technology to problem A simply because they heard it's good for problems A-Z (when it was only ever intended to solve problem H)?

The truth, as we shall see, is rather more uncomfortable. The madness wouldn't be possible without a special breed of person . . . the Stupid Fashion Victim.


What is a Stupid Fashion Victim?

Software fashions come and go, but they always claim a few victims on the way. Where there's fashion, you'll find that rather weak willed person who is the Stupid Fashion Victim (or the SFV for short).

At the risk of over-simplifying, fashion is a marketed trend that is taken up. Fashion victims are those who undertake an inappropriate use of that fashion.

As we discussed earlier, greed is often an instigator of software fashion (at least, of the vendors that try to whip us all into a frenzy over their latest half-baked ideas). In other areas of IT, however, gullibility is often a much bigger contributor to software fashion than greed. The SFV is the entirely gullible person who pounces on some new technology, either because he genuinely thinks it's suitable to base his project on it, or because he thinks it'll look good on his resume.


Popularity vs. Platform Size

As you’d probably expect, fashions are most obvious in the fashion industry. But, today, the software industry is as much a fashion industry as an engineering one. Marketing budgets are huge and are often larger than the budget to develop the software in the first place. When there's not a budget (in the case of freeware) there's also "freehype".

Software fashions get their own little forums on websites such as Javalobby and TheServerSide (TSS), and often invoke religious arguments about the scope of the application of the technology.

Some fashions create lots of small victims and others a few big victims. There’s a perceived inverse relationship between quantity and size of the SFV. Generally the more people that buy into a fashion, the less of a fashion victim you feel. This is of course wrong. A "big" victim is in fact someone who has been royally taken in by the more dubious aspects of the fashion. The more ludicrous the fad, the bigger the victim.

We have all laughed at some of our parent's or children's clothes sense, believing that they just got it wrong. Of course, we also sometimes look at people from older or younger generations and think, they look great – but truth be told, we tend to laugh at their dress sense more often than not. Unless an outfit is being worn by a supermodel, it is generally the 'classic' or 'timeless' looks that fare better. If we don't all want to be SFV's then it's important to understand what is classic and what is hype.

Classic vs hype is basically the same as progress vs fashion. Technology that is useful shows it with longevity. It may start as a fashion, but has so many areas of utility that it ends up with a large profile, as opposed to oft derided niche technology. That's why Java is still thriving 8 years later. That's why JSP is thriving and EJB limping along. It's also why SQL/relational databases rule the roost, but object databases are still pretty unpopular.

With EJB a big issue was remoteness for the sake of it. People imagined that we lived in a Star Trek era, where location, bandwidth and speed were all unlimited. As a result, people created systems with everything remotable, just in case, seeing that as a virtue. When it was eventually realised that this just wasn't working, the EJB spec was "fixed" with the joke that is local entity beans, which rather seems to go full circle.

So what should we look out for in IT fashion? The biggest fashion killer is the ratio of complexity to functionality, or simply Value-Add. The problem with EJB was that you had to put so much effort in to get so little out. It brought back the 'knives and daggers' that Java promised to remove. The latest EJB spec has promised to hide the complexity, but in reality it's too late; IT vendors don’t often get a second bite at the apple (Apple, ironically, being the exception).


Fashion and Zeal Inseparable? You'd Better Believe it!

Another characteristic of IT fashions is zeal. Its proponents often replace reason with faith. Fashion is a 'must have', 'of course it's better', 'everybody else is doing it' kind-of thing.

When I hear this sort of spin I instantly start digging for evidence. I want references. I want details. I want to know how easy, cheap and cost effective it is for me to do what I want. When a technology has been over-egged, a simpler, cheaper, more accessible option will come along and bite you right where you didn't want it to.

So what are the current fashions in the IT industry? We'll pick three principally because of the reasons outlined above, and give reasons for why their adopters may (or may not be...) SFV's.

Our candidates are as follows:

1. VB.Net
2. Struts
3. XP

Each of these has its place when used appropriately (yes, including XP!). However, their widespread adoption and sometimes rampant misuse mark them out as classic software fashions. Let’s look at each one in turn.


Language Candidate: VB.Net

You'd become an SFV if you chose this technology because it’s the poor relation of C#. Firstly, I'm not knocking C# and the .Net framework – whilst immature, .Net is an excellent platform. (It should be, Microsoft ripped off Java so much it's not funny. If plagiarism is the sincerest form of flattery, then Sun must be blushing).

VB.Net, however deserves a bit of a beasting. VB.Net is so different from other versions of VB that there's no migration path from the old code base. VB.Net is really just syntactic sugar on top of C#. C# offers more and better libraries.

In fact, VB.Net was referred to by many as Visual Fred, because it really has nothing to do with Visual Basic.

VB.Net programmers will inevitably either move to C#, or give up and go to work on their parent’s farm. Looking through the .NET developer magazines over the last year shows a diminishing proportion of VB based articles, and confirms my expectation that VB is just waiting for the hatchet to fall. This creates an interesting question, about how well the new VB.Net will integrate into Office.


API Candidate: Struts

The Struts framework does have its place: it definitely solves certain specific problems. In fact, we'd particularly invite Struts advocates to respond to this article by describing the benefits that they feel Struts provides over "vanilla" JSP.

However for many uses, the Struts framework is just too complex. It's just entity beans all over again. When Java was introduced we were promised no more knives and daggers. Just like EJB, Struts introduces unnecessary levels of indirection through a web of XML. In JSP, to get a simple view or edit form up is quite easy, using Struts makes things twice the work. Simple forms are more complex and complex forms are more complex still.

Struts has leapt onto the fashion catwalk, with at least 13 books available on the subject. It's becoming increasingly noticeable that, if you're looking for a job using Java servlets or JSP, then for some reason you have to know Struts as well. Job agencies lump JSP with Struts as if they're the same. "Well, if you're going to use JSP, you'd obviously use Struts!"

Unless you have plans to do one of the things that Struts is useful for (e.g. internationalization), it's just more fiery hoops that you really can't justify jumping through.

It is likely that Struts will either be replaced with a simpler alternative (probably JSF), or backtrack down the simplification route that EJB is now treading. In particular, Struts needs to reduce its use of XML.


Methodology Candidate: Extreme programming (XP)

Extreme programming is surprisingly popular, and has shot to international stardom in just a few short years. However, in many ways it's a victim of its own success. It suffers because it has validly found weaknesses in other methodologies but zealously goes on to build itself in, on and around them.

Because programmers didn't talk to each other much, XP stipulates that they work in pairs. Because programmers didn't talk to the client much, XP stipulates they have a client embedded in the team. Because programmers didn't test that much, XP stipulates that tests must be written before the code. In other words, just because something has a weakness you shouldn’t do the opposite in an extreme form. It’s like bringing the speed limit down to 20 miles an hour below the speed limit because some people have been caught doing 20 miles an hour over the limit.

Ironically, the "proof of concept" XP project, C3, was based on a fixed-spec payroll system - hardly suitable for a development process that is designed for (and even encourages) spec changes.

Methodologies are a power driven aspect of IT, and in that game XP is a negotiating position. Our prediction (and truth be told, this is quite an easy one to make) is that over the next couple of years, the better parts of XP will be synthesized into more traditional methodologies.



Most new technologies have their place; their appropriate usage. Whatever the initial idea, the marketing spin tends to be that fashion X will cure disease Y (e.g. development will become faster, more scalable or more agile). However, a good idea can often be over-hyped to the extent that products get applied in all sorts of crazy, inappropriate ways. You would think that an industry like ours wouldn't be this starved of innovation that we need to hungrily devour every moderately good idea whenever one happens to wander by.

It's important to keep yourself immune from the hype that inflates software trends into fashions. To do this, you need to remain objective: to assess a product or API by its merits (and its originally intended purpose), rather than by how popular it is.

Just think twice before you jump on the fashion bandwagon. Ask yourself: is that new technology going to look like body piercing on your resume in a few years?


0x00 前言0.1 关键字手机自动下载游戏到 手机解锁后提示安装软件 /sdcard/system/download 赛风病毒 如果你的手机内存卡有sdcard/system/32、sdca...
  • pingfangx
  • pingfangx
  • 2016年07月22日 16:57
  • 4601


第46卦,地风升卦。 上回我们说到萃卦,是出类拔萃的意思。好比一堆小苗,你蹭蹭往上窜,窜的比其他都高,这叫做出类拔萃。但是小苗它还得继续长大,就长成了参天大树,不断往上爬。所以萃卦之后的一个卦呢,我...
  • xexiyong
  • xexiyong
  • 2016年12月04日 11:01
  • 629


风辰的CUDA入门系列教程 1. CUDA简介 GPU是图形处理单元(Graphic Processing Unit)的简称,最初主要用于图形渲染。自九十年代开始,GPU的...
  • maosong00
  • maosong00
  • 2013年11月19日 18:32
  • 7105


Unity3D学习      我们来学习风的设置首先不知一个地形场景,还是先单击Assets(资源)倒入Terrian  Creator(地形)包在然后场景里面种上树。         ...
  • driaven
  • driaven
  • 2014年11月18日 13:53
  • 1523


1.风力区域(设置局部风) 添加方法GameObject->Create Other->Wind Zone 其中属性中Wind Main-是设置风力的大小 2.给桥添加碰撞体 首先,需要创建一...
  • imdaixixi
  • imdaixixi
  • 2014年11月15日 21:03
  • 2478


- 1 - 风讯dotNETCMS网站内容管理系统标签说明 一、 风讯dotNETCMS样式表字段说明 内容字段(如新闻内容) 标题:{#Title}是我们在页面能直接看到的内容标题,{#T...
  • diligentcat
  • diligentcat
  • 2015年01月09日 16:01
  • 1202


上回我们讲到了一个最奔波的旅卦,那么我们都知道,在外面奔波久了,就得坐下来歇会,得找个地方待着,所以,今天我们要讲的一个卦是偏向于阴性保守的卦,巽卦。 巽是风的意思,风是最有传递性的,无孔不入,所以...
  • xexiyong
  • xexiyong
  • 2017年01月14日 20:59
  • 501

WIN7+VS2010编译两款2D游戏引擎 风魂和HGE(C++源码)

大名鼎鼎的两款2D引擎不用多介绍了。只是原版的源代码编译环境vc6.0很多无法通过。      所以这次将WIN7+VS2010编译通过的源代码放上。并附上自己找的一些例程源代码  风魂引擎 ...
  • Witch_Soya
  • Witch_Soya
  • 2013年01月09日 17:16
  • 7244

使用风讯CMS系统的痛苦经历 - 真实体验

前一段购买了风讯的CMS 用于网站制作,由于买前没有详细评测,结果在制作过程了经历了非人的折磨,详细如下: 1.首先风讯的帮助非常简单,虽然做了一个视频教程,但是非常肤浅,基本上只能靠猜.功能多多,...
  • zhwxzhwx
  • zhwxzhwx
  • 2007年05月31日 10:55
  • 1308

NOI2015 我的退役之旅

  • Starry__Night
  • Starry__Night
  • 2015年07月21日 23:08
  • 1832