Hacking or Design Patterns?

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

Know Your Flex Proxy

Flex framework includes a pretty useful object that deserves more attention: mx.util.ObjectProxy. You can wrap your object (i.e. Person)  into this proxy which will obediently report on all changes that are happening to this instance of a person.

If you subclass ObjectProxy, you can even add a new  behavior to the wrapped object without touching a single line of its code.

I’ve recorded a short video showing a couple of examples of using proxies in Flex.

This is one of many tricks and techniques that consultants from Farata Systems use while working on enterprise Flex projects, and we’ll continue to share them with you in the form of such mini demos as well as in one of our public seminars like the one on September 24-25 in London, UK (use ebd discount code to get the early bird price) or on October 30 in Atlanta, GA.

For up-to-date schedule of advanced Flex seminars see the section Training  at http://www.faratasystems.com.

Yakov Fain

Upcoming presentations: Flex design patterns – a deep dive

I’ll be delivering an advanced preso on use of some design patterns in Flex at the meetings of New Jersey Flex User Group (Jan 28), New York Flex UG (Feb 19), and Chicago Flex UG on March 18.  Please stop by if you’re in the area.

Here’s a short description of the talk:

Design patterns suggest approach to common problems that arise during software development regardless of what programming language. But implementation of these patterns is specific to the language. The main goal of this presentation is to highlight selected patterns as they may be implemented taking advantages of Flex framework. You’ll see a not so obvious implementation of a Singleton, how a Proxy can dramatically change the behavior of an object, why a Mediator is a must-have in each Flex application. Do you know how to write Data Transfer Objects that are so important in Flex remoting? If time permits, we’ll review the Class Factory pattern too.

This talk is based on some materials from the upcoming O’Reilly book “Enterprise Development with Flex”.

Will be glad to see you at one of these meetings,
Yakov Fain