软件的时髦风

一上班就看到这么有趣的一篇文章……尤其是那句“我最喜欢Decorator模式！我随时都要使用它！”让我捧腹大笑。软件业的时髦的确是非常非常之多，尤其是当创新与时髦紧密融合时，时髦就更成为一种必不可少的元素了。

Software Fashion

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

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

Like 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

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.

 

Conclusion

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?