Software Fashion

[Russel Harvey]

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

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.





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?

 

[Sudsy]

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

F**kin A! Finally someone with the balls to tell it like it is!
This post echoes a number of points I've been making in my
editorials over the past couple of years. I use Struts in the
more complex applications where it saves me from having to
re-invent the wheel. OTOH, I can and have developed solutions
using just servlets.
I also bemoan the overuse of XML in entirely inappropriate
places. What's wrong with properties files? Or simple ASCII
files using tabs or some other simple separator? /etc/passwd
anyone?
I believe that we need to maintain the focus on the end-result
of our efforts, not the tools we use. Someone had the audacity
to post that they wouldn't hire someone who didn't use an IDE
for code development! Using IDEs and Design Patterns, having
familiarity with Dietel and Dietel, et al makes one a better
programmer?!
Thanks for a post which should be required reading for all
developers and their management!

 

[Michael Borgwardt]

I also bemoan the overuse of XML in entirely inappropriate
places. What's wrong with properties files? Or simple ASCII
files using tabs or some other simple separator?

The lack of an ability to formally define the file format and
parse it with well-tested standard code that automatically checks
compliance to that format.

Ill-defined file formats and home-brewed parsing code leads
to all sorts of nasty bugs, among them (in certain languages)
security-relevant buffer overflows.

 

[Roedy Green]

The lack of an ability to formally define the file format and
parse it with well-tested standard code that automatically checks
compliance to that format.

On the other hand, a novice is going to have much more success
composing a syntactically correct properties file than an XML file.

Here is my Properties class that deals with multivalued fields,
separated by commas.

package com.mindprod.replicator;

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.regex.Pattern;

/**
* This class is similar to java.util.Properties.
* The properties file has a similar key=value format.
* However, for MultiProperties,
* spaces in the values are not coded
* as "\ ", just as plain " ".
* Values can be a tuple separated by commas.
* The inherited Hashtable get returns a String[].
* There is no support for extended chars such as \n.
* There is no support for \ as a continuation character.
* Comment lines begin with #.
* Blank lines are ignored.
* The file must end with a line separator.
* All values are trimmed of leading and trailing spaces.
* All Strings are interned, so they behave just like
* hard-coded String static finals.
*
* It is basically just a Hashtable with a load method
* and a few conveniences added to the get method.
*
* @author Roedy Green
* @version 1.0
* @since 2003-08-03
*/
public class MultiProperties extends Hashtable
{

/**
* true if you want the debugging harness
*/
private static final boolean DEBUG=false;

/**
* Constructs a new, empty hashtable with
* the specified initial
* capacity and the specified load factor.
* See http://mindprod.com/jgloss/hashtable.html
* for a full description of
* what the initialCapacity and loadFactors mean.
*
* @param initialCapacity the initial capacity of the
hashtable.
* @param loadFactor the load factor of the hashtable.
* @exception IllegalArgumentException if the initial capacity is
less
* than zero, or if the load factor is nonpositive.
*/
public MultiProperties ( int initialCapacity, float loadFactor )
{
super( initialCapacity, loadFactor );
}

/**
* Load the properties hashtable
* from a text file of key=value pairs.
*
* @param in where to load the textual key=value pairs from.
* @exception IOException
*/
public void load ( InputStream in ) throws IOException
{
BufferedReader br = new BufferedReader( new InputStreamReader(
in ) );

while ( true )
{
String line = br.readLine();
if ( line == null )
{
/* eof */
break;
}
if ( line.startsWith( "#" ) )
{
/* ignore comments */
continue;
}
line = line.trim();
if ( line.length() == 0 )
{
/* ignore blank lines */
continue;
}

// split line into key and value
String[] keyValue = keyValueSplitter.split( line );
switch ( keyValue.length )
{
case 1:
{
// key=nothing
String key = keyValue[0].trim();
if ( key.length() == 0 )
{
complain( line );
}
this.put( key, dummy );
}
break;

case 2:
{
// key=value
String key = keyValue[0].trim();
if ( key.length() == 0 )
{
complain( line );
}
// Split value into subfields
String[] values = subFieldSplitter.split(
keyValue[1].trim() );

// trim the multiple values
for ( int i=0; i<values.length; i++ )
{
values = values.trim().intern();
}
// save in the underlying Hashtable.
this.put ( key, values );
}
break;

default:
case 0:
complain( line );
}
} // end while
br.close();
} // end load

/**
* Complain about malformed data.
*
* @param line Line of key=value that has a problem.
*/
private static void complain ( String line )
{
throw new IllegalArgumentException( "MultiProperties: malformed
key=value : "
+ line );
}

/**
* Get values associated with key.
*
* @param key Key, case sensitive.
*
* @return array of associated Strings, possibly dimension 0.
* If key is undefined returns empty array, not null.
*/
public String[] getMultiple ( String key )
{
String[] value = (String[]) get( key );
if ( value == null )
{
return dummy;
}
else
{
return value;
}
}

/**
* Get value associated with key.
*
* @param key Key, case sensitive.
* @param defaultValue
* Value for the default if the key is not defined.
* key=nothing returns "", not the default value.
* @return String for a single value, or the first of a set of
multiple values, or "".
*/
public String get ( String key, String defaultValue )
{
Object value = get( key );
if ( value == null )
{
return defaultValue.intern();
}
else
{
String[] array = ((String[])value);
if ( array.length != 0 )
{
return array[0];
}
else
{
return ""; // not defaultValue!
}
}
}

/**
* Get single integer value associated with key.
*
* @param key Key, case sensitive.
* @param defaultValue
* Value for the default if the key is not defined.
* @return integer value of the key, or defaultValue if not defined
or if key=
* @exception NumberFormatException
* if the value is not a valid integer.
*/
public int getInt ( String key, int defaultValue ) throws
NumberFormatException
{
Object value = get( key );
if ( value == null )
{
return defaultValue;
}
else
{
String[] array = ((String[])value);
if ( array.length != 0 )
{
return Integer.parseInt ( array[0] );
}
else
{
return defaultValue;
}
}

}

/**
* Get boolean value associated with key.
* Valid values for key are true, false, yes, no, case insensitive.
*
* @param key Key, case sensitive.
* @param defaultValue
* Value for the default if the key is not defined.
* @return boolean value of the key, or defaultValue if not defined
or if key=
*/
public boolean getBoolean ( String key, boolean defaultValue )
{
Object value = get( key );
if ( value == null )
{
return defaultValue;
}
else
{
String[] array = ((String[])value);
if ( array.length != 0 )
{
return array[0].equalsIgnoreCase( "true" ) ||
array[0].equalsIgnoreCase( "yes" );
}
else
{
return defaultValue;
}
}

}

/**
* A dummy empty array of Strings.
* No point is allocating a fresh one every time it is needed.
*/
private static String[] dummy = new String[ 0 ];

// Pattern to split line into key and value at the =
private static Pattern keyValueSplitter = Pattern.compile ( "=" );

/**
* Pattern to split into words separated by commas.
* Two commas in a row in the String to be matched gives an empty
field
*/
private static Pattern subFieldSplitter = Pattern.compile ( "," );

/**
* test harness
*
* @param args not used
*/
public static void main ( String[] args )
{
if ( DEBUG )
{
MultiProperties m = new MultiProperties ( 100, .75f );
try
{
m.load( new FileInputStream ( "replicator.properties" ) );
}
catch ( IOException e )
{
e.printStackTrace();
System.exit( 1 );
}
for ( Enumeration e = m.keys(); e.hasMoreElements(); )
{
String key = (String) e.nextElement();
String[] values = m.getMultiple( key );
System.out.println( key + " =");
for ( int i=0; i<values.length; i++ )
{
System.out.println ( values );
}
} // end for
} // end if DEBUG
} // end main
} // end MultiProperties

 

[Ike]

The things that persist, can be distillied down to "The elements necessary."

Examples over the past decades of things that are more than mere fads:
1. "Structured Programming"
2. OOP & "Componentized" software
3. Event-Driven notions, as opposed to top-down, necessitated by GUI's.
4. Virtual Machine's, necessitated by different OS's & Gadgetry.

I'm certain there are others, but these are the real milestones I have
witnessed in my life. With each of these, I might add, there was always a
certain degree of pain, a restructuring in my own mind, of how to approach
programming.

//Ike

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

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.





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?

 

[Matt Stephens]

Thanks for posting that, Russel. You forgot to mention that the
article originated from here:

http://www.softwarereality.com/soapbox/softwarefashion.jsp