Software Fashion

Discussion in 'Java' started by Russel Harvey, Oct 10, 2003.

  1. 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?
     
    Russel Harvey, Oct 10, 2003
    #1
    1. Advertising

  2. Russel Harvey

    Sudsy Guest

    Russel Harvey wrote:
    > 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!
     
    Sudsy, Oct 10, 2003
    #2
    1. Advertising

  3. Sudsy wrote:
    > 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.
     
    Michael Borgwardt, Oct 10, 2003
    #3
  4. Russel Harvey

    Roedy Green Guest

    On Fri, 10 Oct 2003 15:02:33 +0200, Michael Borgwardt
    <> wrote or quoted :

    >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


    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Oct 10, 2003
    #4
  5. Russel Harvey

    Ike Guest

    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



    "Russel Harvey" <> wrote in message
    news:bm5e9a$iff5v$-berlin.de...
    > 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?
    >
    >
     
    Ike, Oct 11, 2003
    #5
  6. Matt Stephens, Oct 11, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Progman
    Replies:
    0
    Views:
    346
    Progman
    Mar 6, 2006
  2. Replies:
    5
    Views:
    12,005
    Andrey Kuznetsov
    Jul 12, 2006
  3. alf
    Replies:
    9
    Views:
    309
    Colin J. Williams
    Mar 17, 2007
  4. John
    Replies:
    0
    Views:
    1,090
  5. John
    Replies:
    0
    Views:
    1,092
Loading...

Share This Page