IT Failures as a Function of Poor Programming Languages

There is a commonly held myth in our industry, the myth of the "mediocre average developer". Of course, some 90% of developers consider themselves to be above average as they make fun of their less brilliant colleagues, but I won't digress over that particular paradox.
There may be some truth in the assertion that "average" is mediocre - there certainly is a lot of unwillingness to learn, clinging on to sunk cost ("I've spent 10 years mastering Java! I'll ridicule anything new to avoid having to invest in something new!") and general backward conservatism interspersed with the odd mad dash of silver-bulletitis.

The Developer, The Tools, or Both?

I've written before that knowledge and mastery of one area is simply not enough. The totality of your knowledge and ability across a number of disciplines is more important than mastery of a single one. Similarly, tools and languages matter. All programming languages are not equal.

I would assert that as big, if not a bigger culprit in the mediocre results yielded by many corporate IT projects are the tools and languages used. Java is the dominant platform for enterprise development these days, yet as a language it suffers from an atrocious laundry list of horrible short-comings.

Lets inspect a rather contrived example of poor code that is very easy to write and not acknowledge as poor before it bites you:

public class Basket{
  private List<LineItem> lineItems = ...

  public List<Product> getProductsOfType(String type){
    List<Product> products = new ArrayList<Product>();
    for(LineItem item : lineItems){
      if(item.getProductType().equals(type)
        products.add(item.getProduct());    
    }
    return products;
  }

  public Product getHandset(){
    List<Product> handsets = getProductsOfType("handset");
    if(handsets.size() > 0)
      return handsets.get(0);
    return null;
  }
 
  public boolean hasHandset(){
    return (getHandset() != null);
  }

}

You could easily write unit-tests that would assert the perceived correctness of all of the methods in the example above, yet there is a rather nasty potential bug that lurks in its midst, can you spot it?

Found it? No? It's in "hasHandset()". Still not found it?
Ok, here goes: What happens if the "getHandset()" if a LineItem returns null? The List will get a "null" item added to it, handsets.get(0) in getHandset will work, but return null, hasHandset will return false as a consequence. Is this the correct behavior of the code? Maybe, maybe not, it really depends on the relationship between LineItems and Products, do LineItems always have Products, or is it simply a "soft reference" of sorts, whereby a Basket can have handset LineItems without requiring to have immediate access to the underlying product. Either way, it is not immediately obvious, and a developer ("average" or not), could reasonably make either assumption.

Java, the Language, Is a Contributor to IT Project Failures

As I mentioned, the above code might easily come about. Especially if it evolves over time at the hands of several developers. It is an excellent example of how unpredictable bugs can creep in due to the nature of the language and the way it encourages you to program. It's just a matter of code entropy that creeps in over time.
To make a non-exhaustive list of some of the shortcomings that Java not only has, but encourages you to do:

• Mutability - Java allows immutability, but it is not the standard mode of development.
• Mixing data and "functions" - possibly the biggest culprit together with "null" in the example above. The fallacy of "objects" bites you hard.
• Inheritance and sub-typing - inheritance is bad. Just use composition, ok?
• null as a means of expressing "nothingness" - I think a "billion dollar mistake" is an understatement.
• Inexpressiveness, verbosity. Strange side-effects become the norm due to inexpressiveness.

This is just a short list off the top of my head in a couple of minutes. It is far bigger than that if you would take everything into account. Yes, you can work around most of these shortcomings, good developers will know how, but the language still nudges you in directions you shouldn't go by virtue of its nature and the resulting entropy from the combination of time lapsed and developer churn will eventually outweigh the skills of individual developers.

To make it clear, Java is not a single contributor to Enterprise IT failures, in the grand scheme of things, it's probably a small contributor, but I believe it certainly is a contributor. All parts count, and the language is the nuts and bolts at the lowest level. If you are building a skyscraper from materials that are structurally unsound, you may find yourself getting sub-optimal outcomes. The same goes for programming languages and software projects. Incompetence and lack of skills may play their part, but any incompetence will be vastly amplified by poor, unsuitable tools.
A programming language is an amplifier of skills. Make sure you choose one that is a positive, not a negative amplifier.