Review: Head First Design Patterns

I picked up Head First Design Patterns by Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra while working through some particularly difficult design/code reviews.  In these reviews, I found that very few developers actually knowingly use design patterns beyond the most simplistic of forms.  In fact, during several interviews, I asked candidates what design patterns they could name and most could not name a single one.  However, when I asked them if they had heard of the Singleton Pattern, they immediately began giving examples of writing code to meet this pattern.  With this discovery, I quickly began recommending this book to java developers of all levels as a way to renew why we design code the way we do.

Head First Design Patterns quickly gives the reader exposure to some of the most common patterns and why they work.  Does this book cover every possible pattern and the intricacies in its use?  No.  However, it brings to the reader a mode of thought that begins to look at design patterns as a way to solve common problems without “reinventing the wheel.”  The examples are relatively simple to understand and the writing style straightforward and logic in its flow.

I recommend Head First Design Patterns to any entry through advanced level developer or designer in the object-oriented world that desires to find a solution to common problems in a way that allows your design/code reviewer and maintainers the ability to understand why the design/code was “done” the way that is was “done” in a less-than-four-hour line-by-line review meeting.

SOA Governance Control the Chaos

With the growing number of implementations in the development community based on the SOA (Services Oriented Architecture) paradigm, I see many different governance mechanisms stated in terms of “must”, “shall”, and “only” when someone has begun an implementation of SOA. In this post, I will discuss some of the observations I have seen in my 8+ years of working in the SOA paradigm and provide some advice on how to better manage one of the stickiest areas of SOA implementation – governance.

SOA Governance is probably the most misunderstood area of a SOA implementation in our organizations or projects. Even the community contributors to Wikipedia struggle to provide a single and concise definition for what SOA governance “is.” There are many academic reasons for this struggle, but the overriding reason for this struggle is that governance is a term that means different things to different levels in an IT organization. To the technical manager, governance is controlling what tools, resources, and processes their development team will utilize. To the developer, governance is controlling how they create a service, how they integrate them with other services, and generally how they should be built. To the architect, governance is about controlling what specific services are built, their interactions, the domain of responsibility they satisfy, and how well they can be reused.

With all of these multiple pulls at a SOA governance process, a person can quickly see why there are so many flavors of governance implementations around the community. With the exercise of outsourcing the development of SOA implementations to remote organizations, the puzzle of governance is even more complicated since motivations such as financial, domain control, and experience-to-cost situations arise. I will not be able to cover all of these complicated issues into a single model everyone can follow in every implementation (hence why this is an issue in the first place), but based on my experiences in the SOA Governance model, I will try to provide some simple recommendations that might make the implementation of governance easier for all of these different types of teams.

Understand SOA Governance’s level of control.

The first mistake an organization can make in implementing SOA Governance is to try to control the lowest level of decisions being made in the implementation of SOA services. For example, defining every development tool that a team should use in the implementation of the service is a recipe for disaster. I am not saying that there should not be guidelines around this tooling – only that there has to be a sense of reasonableness and flexibility to prevent teams from needing to “force” a tool to do something it is not really designed to do well. For example, in a presentation at JUG, an architecture member presented their “Toolset Recommendation for SOA Implementations.” It looked something like this.

It was explained to the room that the developers were advised that if they did not use these (and only these) tools in their service development, that their implementation would not be approved by the governance board and hence not eligible for implementation. I can’t fault them in attempting to resolve a major issue in most development communities: toolset control/toolset domain knowledge. After all, how many times have we all been on a maintenance effort where we find that the previous team used an obscure library that takes us days to figure out how to use (much less find a download or instructions for in the community)? However, while their approach was a valiant attempt towards a resolution to these common issues, I believe that it causes a condition I like to term as “over-control.” In my experiences, any approach that causes over-control will generally cause it to fail.

As an example of a condition of over-control; what if a service implementation contains a requirement to provide session support? In Apache CXF, session support is not supported out of box due thread-safe risks. While this condition can be mitigated through the use of some of the tricks of the trade, a different Service framework may have made this implementation easier to develop successfully. However, in the case above, the SOA Governance “standard” required the use of a single service framework. Therefore, the team is quickly out of compliance with governance for picking a different service framework and either fails to implement or implements potentially buggy workarounds to change to the governance standard.

How do you resolve this conflict? Create a toolset board that contains all of your brightest and most reasonably vocal of senior developers. That board should provide multiple recommended toolset options for each framework area. For example, the board should use their past experiences and combined knowledge to define recommended toolsets including documenting each tool’s “sweet spots” and “limitations.” This information should be readily available to the projects teams as then begin lower level design. However, the most important feature of this process is to allow the projects teams to challenge/add new toolsets to the standard through the board. If that case is accepted, the organization as a whole will benefit from the experiences of its project teams, the governance standards stay current and flexible, and projects teams don’t implement a toolset that has known issues identified by the other projects teams. With this approach the governance document for approved toolsets would look like the below (simplified view).

With these types of toolset control mechanisms implemented in SOA governance, we get the best tools being chosen for each of the areas of our implementations along with growing our organizations and development communities. In the end, we have achieve the needs to each of our organizational areas: the development managers get a list of tools to ensure core competency in their teams, the developers get their flexibility and some experience-based advice, and architecture gets their reuse and standardization.

Coding Standards: A Beginning

010712_1933_SOAGovernan1.pngWhile working on a proposal for a new open source incubator project, it came as no surprise that the topic of which coding standards we should use came to the top of my task list as code formatting arguments were raised.  In a flash of inspiration, I immediately provided the standard quick and concise answer:  “Lets use the Oracle Java Coding Conventions standard.”  Suddenly, the sun burned brighter and the birds took up in song as the brilliance of my efficient answer was delivered.  Later in the day, when I had more time to consider the ramifications of my earlier answer, I pondered that perhaps I had been too simplistic in the view of what the Coding Standards means to me, my project, and the information technology industry as a whole.

So…let’s be honest with ourselves here.  When push comes to shove, we do what we need to do to get the product out to the markets. How often do we tell ourselves, “who really cares if I used 5 or 10 spaces of indent” and “Why does anyone care that all of my variables contain a single letter?”  We know that true “format” issues don’t really matter to anyone other than only the most critical of code reviewers.  Also, we always tell ourselves that we will get back and fix all those little shortcuts we took (no comments, JavaDoc statements, commented out code, etc) just as soon as we have a little more time.  Besides, we also all know that badly “formatted” code runs in production just as well “formatted” code…right?

However, as I found some free time to myself  (aka the holiday period), I wondered if perhaps there were some things that are defined in high-quality Coding Standards that are perhaps a little more complicated that pure formatting.  An example of one of those items is found below.

STRUCTURE GUIDELINE – “Avoid nested method call at all costs unless it is completely guaranteed not to throw an NullPointerException.”

Example #1

this.theInstance.theMethod.getMap.get(“key”);

In the above example, there is a good possibility that this efficiently written single line of code will return a NullPointerException to the caller.  Code reviewers generally see samples of where this exception prone code is wrapped (usually later) as the example bellow shows.

Example #2

  1. try{
  2.      this.theInstance.theMethod.getMap.get(“key”);
  3. } catch (NullPointerException npe) {
  4.      log.error(npe.getMessage(), npe);
  5. }
  6. return npe;

When the NullPointerException message is inspected from the code above, the stack trace will tell you the line number that caused the exception (line 2), but cannot tell you if the Null object in this line was theInstance, theMethod, or getMap.  Suddenly, we begin to realize that perhaps high-quality Coding Standards can help us write more “reliable” code.

In summary, delve deeper into the coding standards available in the community and consider if your projects should use code formatting tools such as Checkstyle (my current preference) in their efforts.  It worked for me and hopefully it will work for you also.