Earlier this year, I made a statement defending hacking in an interview for Oracle. Yesterday, I found a thread on theserverside.com where java developers were sharing their view on the subject. In this blog I’ll take the same two quotes there ignited some arguments and will try to explain my point of view.
1. “Recently, I’ve been running a seminar for a small group of Java developers. Several times they’ve asked me, ‘Is this code an example of MVC pattern?’ I got the impression that implementing MVC had become an end in itself. Using Design Patterns is not a dogma. Just write the code that makes sense. Not everything that makes sense has a named design pattern.”
2. “Abusing design patterns is not always the fault of Java developers. I find the approach used in the enterprise software shops similar to medicine in the US. In my opinion, lots of doctors here practice ‘protective medicine.’ They are trying to protect themselves from malpractice law suits. Enterprise managers and tech leads also try to minimize the risk introduced by lower-skilled developers who are part of every team. Yes, abiding to object-oriented principles definitely helps in making code readable, but this does not always translate into better performing applications. If hacked-up code produces great results, apply it without worrying whether another developer will have problems understanding it.”
I work for Farata Systems, a consulting company that makes a living by developing rich Internet applications utilizing Adobe Flex and AIR and Java EE. We are a small company (about 30 people). We do consulting as well as develop our own software (both commercial and open source). The number 30 is important here. Many years ago, a respectful person taught me that until the company is under 30 people it’s efficient because there is no need to hire middlemen managers. The founders of the company can run the projects themselves, and there is no ballast.
After several years of running the company with two other geeks, I couldn’t agree more. We can afford to cherry pick developers, which large company can’t. I’ll tell you more – we can afford having people who don’t have to stick to design patterns just to ensure that Joe Smith who became a programmer after attending 6 months of vocational school will understand the code. We can afford to build teams not with code monkeys who were shoved into our throats “because XYZ is our offshore partner and we have to keep them busy”. We are also working with offshore developers, but only with those who can do the job and can read/write the code regardless if it belongs to M, V, or C tiers.
Design patterns were not created equal. It’s OK to bash Singletons. They are easy to be blamed for being a replacement for global variables. But MVC is still considered to be good. Unfortunately, it’s not about three tiers any longer. Java architects enjoy creating layers. They’ll be happy to explain anyone how these extra layers will make your application very configurable and flexible. Layers are best friends of consulting firms who have sharpened their skills in creating beautiful powerpoints with nice round-square rectangles filled with color gradients. Thick arrows going from left to right shows how “with our consulting company you’ll move from here to there in just a couple of years”. The arrows must leave no doubts in the minds of hiring managers that “these guys can do it”.
And most importantly, these multi-tiered diagrams will explain the hiring manager of a large corporation that it’s OK that Satish is weak on the front end and Boris never worked with the back end…if you know what I mean. This multi-tiered design can turn both Satish and Boris into code monkeys who will do nothing but inserting their business logic into easy to understand location and the framework will do the rest. Design patterns promote the lowest-denominator-skills software development.
You may be surprised, but even such a sacred cow as dependency injections is not a must. Believe it or not, pretty much any application can be created without DI. I’m not kidding. No XML configuration files to process. Popularity of dependency injection in the middle tier is based on the necessity of integration techniques to allow upgrades and replacement of large pieces of technology with their new implementations. To be fair, I need to praise Java EE 6 for smart and light implementation of DI that doesn’t make you drown in XML.
Applying DI in the front-end applications on top of the frameworks with well designed event model is an overkill on the desktops and suicidal on smart phones and tablets that need to be optimized for memory and speed. We see bigger consultancies still doing it because it is a proven and easy to sell solution. Unfortunately, starting a new Flex project with an analysis of which MVC framework to choose seems to become a habit in enterprises.
My interview statement that writing the code that works is the ultimate goal is applicable only in teams that can afford to employ skilled professionals. If for whatever reason you can’t, go with the flow and rely on injections that somehow will put the collection of Orders into your Customer object.
Finally, to make this blog even more thought provoking, I’ll touch upon yet another sensitive subject. Who do you need to write code for – humans or computers? On one hand, the code must be readable, cause the same piece of code is being read a lot more often than being written/modified. On the other, the code must be efficient. For example, in financial trading applications adhering to design patterns is a low priority item. Speed is the king there.
Recently, I showed one chapter of my new Java tutorial to a very experienced Java developer. He was surprised that I included an example of BitSet there. This is what he said – word for word, “Perhaps your experience is different than mine, but I don’t think I’ve ever seen this class used in practice. It really feels a bit old-fashioned, and C-like. In 2010 I’m not sure anyone writing code in Java really worries about this level of saving bits. Maybe it still relevant in some embedded systems, but do those systems actually run Java?”
Ten years ago I was working on developing an equity trading system for a Wall Street company. It was a J2EE application with a heavy use of messaging. A trading order had to be sent to a queue, and this was an object with about 50 fields with yes/no values. Using BitSet for sending a set of flags (bits that are set to 1 or 0) instead of text or numbers is the most economical way to do this. Did I care that a programmer who’d be reading my code a year from now won’t immediately understand that just a couple of bytes carried had tons of information about the order? I did not. This piece of code was not readable, but efficient.
IMO, in the ideal world of inhabited by skilled software engineers, the code has to be written for computers. But we don’t live in the perfect world. So I don’t insist.
Yakov Fain
