Intelligent Design Patterns Part 1: Black Coffee Software

Being a transplant of the great white north to the proud state of Alabama, I was thrilled when the state's first Dunkin Donuts opened about two miles from my office. We have a couple of Starbucks close by, but until about a year ago we were painfully without Dunkin. For those of you outside of the United States, in our country the Dunkin vs. Starbucks question has become sort of a cultural litmus test based on the true fuel of American innovation: coffee. An order at Dunkin usually reads along the lines of "Large Coffee, Black." Starbucks, of course, is famous for its ability to build drinks more complex than non linear algebra containing contributing ingredients from more countries than the international space station. A Starbucks order must be at least 18 syllables  and run along the lines of "Venti half soy, half 1 percent, cream mocha vanilla latte with splenda, add a split quad shot with whip and caramel. Extra Hot."

To Dunkin fans theirs is the choice is one of simplicity - of getting the job done with no bells or whistles. To them, a Starbucks coffee is complex for complexity's sake, and contains unnecessary ingredients that do little to advance the coffee drinking experience but increase cost and obfuscate any attempt to understand one another's drink orders. Its customers are pretentious at best, and quite possibly un-American at worst.

To Starbucks drinkers, theirs is the more evolved palate. Their orders simply cannot be appreciated by the cretins of DD, who they will not rule out as a potential lower life form stuck in a rigid coffee drinking pattern and unable to adapt to change should the need arise.

So which group of loyal customers is right and which is wrong? Of course this a question that can't be answered - there are simply too many variables, too many circumstances, and too many considerations of personal taste.

So if all this is true for something as simple as a caffeine fix, why do I see this same debate in software design? I see endless discussion between the developers who think that every application should be split into independent cross functional tiers to form a true SOA, using an automated IoC container for every object instantiation, whose service access points are always hidden from the model layer using a facade pattern, then logging events for the entire whole application by sending messages to an enterprise service bus attached to a separate logging repository modeled after SaaS in the company's private cloud, and the developers whose idea of a design phase is a 20 second whiteboard sketch, immediately followed by the creation of a single layer web forms application where each button click handler opens a connection to the database and binds the results set directly to a grid control using a SqlDataSource object.

If you are like most software developers, you probably found yourself nodding sagely with one of these strategies, and growing simultaneously angry and nauseous with the other. Which one you agree with and which one provokes a violent reaction will depend on your own personal view of software development and design. Now we are left with the same conundrum: which group of developers is correct, the black coffee coders or the mochachino architects?

Again, I would argue that the answer is highly situational  Anyone who has built software can tell you that there are literally hundreds of ways to implement any given set of requirements, but not all patterns are created equal. No one strategy of software design is going to be correct for every application. Proper technical design complexity (which is very different from code complexity)  for enterprise software is dependent on the answer to many business level questions:

• Who is the target audience of my application?
• Am I developing a product, or a one time solution?
• What are the chances the customer will want me to add new modules to my application?
• How stable are my integration points?
• Are there any complex business rules that the application needs to implement, or is this a data entry and reporting application?
• How will external applications consume my solution's data?

No one rocks the pince-nez
quite like Chekhov

Thus far, I've been talking very abstractly about complex and simple software design, and haven't gotten into specifics at all, and I probably sound a bit like a college professor replete with pince-nez glasses. Complexity isn't just about the abstract or the high level. Yes, making the determination between a one, two, or three tiered architecture determines a great deal about the complexity of your system, but just as important are some of the key design patterns that have been cropping up more and more during enterprise development, especially for web applications. Each one of these paradigms has specific circumstances where they should be used, and others where they can actually end up costing your project time (and therefore money) in the long run, with no measurable benefit. Unfortunately, each has its adherents who believe that their pattern of choice should be used in nearly every circumstance. In this series of posts, we'll consider some of the more popular software design patterns and paradigms:

• Service Oriented Architecture
• Instantiation Patterns (Dependency Injection vs. Abstract Factory vs. good old new)
• Test Driven Development
• Facade and other Abstraction Layers
• Object Relational Models
• Message Queues and Services Busses

For each of these patterns, we'll identify why the pattern exists in the first place, what potential benefits it brings to your application, what the associated costs of inclusion are to the project, which of the above business questions above apply to that particular pattern, and finally we'll discuss scenarios where the technology is appropriate, and where it will end up costing your project more than it's worth. After all...

Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. - Einstein

... and that, perhaps, is the key step in making the transition from a great coder to a true software engineer.

P.S. I enjoy both Dunkin and Starbucks and have ingested not insignificant quantities of each while writing this series of posts. Sometimes you need a black coffee, sometimes you need a venti skinny iced hazelnut latte. In life - as in software development - the answer to the question "how do you like your Java" is highly situational.

Next > Part 2: How Service Oriented is Your Architecture?