Earlier this year, in an interview for Oracle, I made a statement defending hacking. 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 that 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 over 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 a 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 okay to bash Singletons. They are easy to be blamed for being a replacement for global variables. But MVC is still considered to 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 to the hiring manager of a large corporation that it’s okay 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.

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. 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.

My 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.

Read the original blog entry...