The pendulum has swung once again and I have escaped the world of architecture to get back to delivering software. I left Bank of America (Countrywide) for the second time last week, but not the mortgage industry. I am now the Application Manager for the origination system Nationstar Mortgage.
The challenge for my first week has been getting my head around the codebase. The application is a combination of a vendor solution along with a lot of custom code built up along the side. Like a lot of in house applications which started small, this one has grown in to what I call the “big ball of mud” pattern, where there was not the long term vision and architectural rigor for structuring a scalable, maintainable application. The fun part is it is my job to fix it.
After a week of looking at code, I have acquired new-found love for strong typing. In a mad genius, army-of-one development mode, the freedom of dynamic languages is both liberating and powerful. But as you start to add more cooks to the kitchen, things start to go downhill rapidly.
Case in point, I was attempted to troubleshoot a sporadic NullPointerException that pops-up in production. The culprit method is getting an object out of a list, and calling a method on a nested object it contains. I’m trying to determine if the object itself is null, or if the nested object is missing, so I’m tracing back how to where that object comes from.
The problem is that the instance of the object comes from an ArrayList, which is created from an object in HashMap, and neither makes use of generics. I know what my final object is supposed to be, but I have to trace back through other code to see how that the HashMap is being populated with.
This whole codebase has left me begging for generics. Generics in Java are not just about type safety, they are about documenting your code. For example, instead of:
ArrayList myLoans = new ArrayList(); HashMap properties = new HashMap();
You should make use of generics so that other people aren’t left guessing on the contents:
myLoans = new ArrayList (); Map properties = new HashMap ();
In the second case, I know I have a list of Loan objects, and I know I have a map where the key is a String and the entry is an Address object. I don’t have to jump around in the code to see how they are used to understand exactly what they contain. Note another difference: I use the collection interfaces (List, Map) in my declaration rather than the implementation classes (ArrayList, HashMap).
From an object-oriented programming perspective, you should always strive to hide the implementation details of objects. And by using the interface, you buy yourself the flexibility of being able to swap out for a new implementation class without breaking the code. For example you could change the ArrayList to a Vector if you needed the synchronization and not break downstream code.
So with my dive back in to the bowels of enterprise software development, I’ve regained a new appreciation for my old friend Java. There is great strength in strong typing which permits you to build much more maintainable applications than the alternatives. Use that strength and make your team happy.