Tuesday, December 28, 2010

Deceptive Software Products

Products to the naked eye look marvelous from the outside to the unsuspecting of us. I like to think of products (in particular software) as looking like this beautiful house:


Amazing isn't it? Beautifully laid out, marvelously sleek design, and inviting. The software may appear to have all qualities, but what about its foundation? Is it as solid and good looking as it appears?

Software users usually do not ask the latter and with good reason: They are abstracted from this because software professionals are suppose to ensure that the foundation is good. The problem is some IT managers and teams do not care about quality and are all about – “get it into production and forget the rest.” Do not get me wrong, I am all about pleasing the users and getting things into production as soon as possible, but when the number of hacks increase, and there are no unit tests or other testing methodologies in place to come back and confidently fix the hacks in the next release -- this leads to the eventual degradation of the product. Maintenance will become a nightmare, new features will sometimes have to be hacked in, developers will become afraid to change the code for cleanliness and maintainability purposes, and the broken windows theory will kick into full gear. This is a recipe for disaster in my eyes and will lead to developer dissatisfaction if proper measures are not in place.

When architects/engineers build bridges and houses, they pay close attention to detail and do not over or under promise things. In the software industry, we constantly see people offering the world and a cure for cancer to boot in the first or next version of its software. This in my opinion is part of the reason why at times software looks the way it does from the inside. For instance check this nasty Java hack:


public void foo(Object paramObject) {
...
...
 Object someObject = null;

 if (paramObject instanceof String)
 {
    if(“Y”.equalsIgnoreCase((String)paramObject)) 
       someObject = “Y”;
    else if (paramObject == null || “N”.equalsIgnoreCase((String)paramObject) ||         
             “”.equalsIgnoreCase((String)paramObject))
    {
       someObject = “N”;
    }

    //some other hacky hard-coded non-sense
 }
...
}



This one happens to be one of the most appalling Java hacks I have seen:


public interface SomeInterface {
  public boolean isConditionValid();
  public Results getResults();
}

public class SomeClass {
...

 public void foo(List<SomeInterface> list) {
  ...
  for (SomeInterface iface : list) {
   if ( iface instanceof ConcreteObjectA && iface.isConditionValid())
   {
      ConcreteObjectA a =  (ConcreteObjectA) iface;
      logger.debug(“A ConcreteObjectA is a part of the collection: ” + a.toString());
      doSomethingWithTheResults( a.getResults() );
   }
   else if(iface instanceof ConcreteObjectB && iface.isConditionValid())
   {
      ConcreteObjectB b = (ConcreteObjectB) iface;
      logger.debug(“A ConcreteObjectB is a part of the collection: ” + b.toString());
      doSomethingWithTheResults( b.getResults() );
   }
   //and more and more instanceof hacks below
  }
 }
}


This may not appear to be that bad for some but for me I find it deplorable. The same developer who wrote this, if left to his own devices, would destroy the product in no time with this kind of code. No understanding of polymorphism, object hierarchies, or design; really no understanding of anything other than javac and java commands. This individual is making a six figure salary writing this kind of garbage! Excuse my indignation but it upsets me that this same developer would go out of his way to bash software development and proclaim that is merely all just another if statement. Yes, it may appear to be easy on the surface, but proper design and coding techniques are rewarding, hard work, and part art - part science. These samples represent the worst in coding style and design, and are the reason software systems have shady/fragile foundations. I may submit the code to CodingHorror.com and also write a book called “101 coding hacks I have seen” or “Hacks r us”.

I know better when I see the product built with code like this and see it from the foundation upwards this way:


Time to put on the hard hat and get to work!

Follow me on Twitter mrosario2012

No comments:

Post a Comment